COMMAND

    S/Key & OPIE Database

SYSTEMS AFFECTED

    BSD/OS   4.0.1   (SKEY),   FreeBSD   3.4-RELEASE   (OPIE),   Linux
    Distributions (with  skey-2.2-1 RPM),  Any Unix  running skey-2.2,
    (possibly earlier versions too)

PROBLEM

    'harikiri' found  following.   A vulnerability  exists on  servers
    actively  using   the  S/Key   or  OPIE   authentication.     This
    vulnerability enables local  users to obtain  access to the  S/Key
    or OPIE database.  Implementations/installations of S/Key and OPIE
    on other operating systems should be reviewed.

    S/Key  is  an  authentication  mechanism  which  enables  one-time
    passwords  to  be  used.   The  system administrator may configure
    users to  use S/Key  for authentication  on any  service that uses
    login(8), such as Telnet and FTP.  The configuration file used  to
    specify the  authentication type  to use  is /etc/login.conf.   To
    configure a user to use S/Key, the administrator, or the user  (if
    the program  is setuid  root) must  first use  the skeyinit(1) (or
    keyinit(1)) program.   This program  initialises the  user's entry
    in  the  S/Key  database,  /etc/skeykeys.   This file contains the
    authentication  information  that  entered  (S/Key)  passwords are
    compared against.

    OPIE (One-time  Passwords In  Everything) is  a one-time  password
    scheme  based  on  S/Key.   It  features  some enhancements in the
    implementation,   but   remains   very   similar   in   terms   of
    administration goes.   The differences  as far  as it  compares to
    S/Key are  that the  opiepasswd(1) utility  is used  to create new
    entries, and the database file is /etc/opiekeys.

    S/Key:
    ======
    When skeyinit(1)  is used,  the libskey  function skeylookup()  is
    called.   If  the  /etc/skeykeys  database  is  not present, it is
    created with  a mode  of 644.   This results  in a  world-readable
    file.  The problem code is shown below (from skey-2.2):

        /* See if the _PATH_SKEYFILE exists, and create it if not */
        if(stat(_PATH_SKEYFILE,&statbuf) == -1 && errno == ENOENT){
                mp->keyfile = fopen(_PATH_SKEYFILE,"w+");
                (void) chmod(_PATH_SKEYFILE, 0644);

    OPIE:
    =====
    When opiepasswd(1) is used, the libopie function opieopen() is
    called.  The two functions which call opieopen are opiereadrec()
    and opiewriterec().  Both functions call opieopen and specify a
    mode of 644.  If the /etc/opiekeys database is not present, a file
    is created with this mode, resulting in a world-readable file.
    The problem code is shown below.

    opiereadrec:

        if (!(f = __opieopen(KEY_FILE, 0, 0644))) {

    opiewriterec:

        switch(i) {
        case 0:
          if (!(f = __opieopen(KEY_FILE, 1, 0644)))
            return -1;
          if (fseek(f, opie->opie_recstart, SEEK_SET))
            return -1;
          break;
        case 1:
          if (!(f = __opieopen(KEY_FILE, 2, 0644)))
            return -1;
          break;
        default:
          return -1;
        }

    Thus, local  users have  permission to  read the  contents of  the
    /etc/skeykeys file.   Whilst the  secret password  information has
    been stored in a message-digest format (MD4 or MD5), a  dictionary
    attack may be undertaken to obtain the plaintext passwords.

SOLUTION

    It  was  confirmed  that  FreeBSD  3.4  and  OpenBSD  2.6  are not
    vulnerable to  the S/Key  issue.    FreeBSD and  OpenBSD appear to
    have taken the S/Key seriously, and created an empty /etc/skeykeys
    file with mode  0600.  Thus,  subsequent modifications by  keyinit
    will  not  render  the  file  world-readable.  Vendors and package
    maintainers  of  S/Key  and  OPIE  should  consider following this
    practice.

    The vulnerability stems from a file permission error and is simple
    to correct.   On your  system, execute  the following  command (as
    root):

    S/Key:

        # /usr/bin/chmod 600 /etc/skeykeys

    OPIE (FreeBSD):

        # /usr/bin/chmod 600 /etc/opiekeys

    This  will  however  have  the  secondary  effect of rendering any
    application  that  does  not   have  root  privileges  unable   to
    authenticate  against  the  database.   Thus  it  becomes  a  risk
    mitigation issue.  You may either:

        (a) Leave it world-readable and risk the threat of password cracking; or
        (b) Remove world read privileges, and enable relevant applications
            appropriate privileges to access /etc/opiekeys.

    NetBSD began installing a mode 600 /etc/skeykeys file as of Jan 6,
    1999.   This issue  would not  affect the  two most  recent formal
    releases,  1.4,  and  1.4.1  -  as  they  include  the more secure
    default.   Users  of  skey  on  earlier  installs  should evaluate
    appropriate  permissions  for  their  /etc/skeykeys  file based on
    local   requirements   (e.g.   non-setuid   programs    performing
    authentication) - as indicated in the advisory.