w00w00 Security Advisory - http://www.w00w00.org

Title: 		S/Key & OPIE Database Vulnerability
Platforms: 	BSD/OS 4.0.1 (SKEY).
		FreeBSD 3.4-RELEASE (OPIE).
		Linux Distributions (with skey-2.2-1 RPM).
		Most Unixes (not NetBSD) running skey-2.2. (possibly earlier 
                versions too)
Discovered:	14th January, 2000
Local:		Yes.
Remote:		No.
Author:		harikiri <harikiri@attrition.org>
Vendor Status:	Notified.
Last Updated:	21st January, 2000	


1. Overview

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.

I can confirm that FreeBSD 3.4 and OpenBSD 2.6 are not vulnerable to the
S/Key issue. Implementations/installations of S/Key and OPIE on other
operating systems should be reviewed.


2. Background

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.


3. Issue

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;
  }


4. Impact

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.


5. Recommendation

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.


6. Discussion

>From what I can see, this bug is a hangover from the days of old when you
could trust local users to behave. Times have changed, but this program
hasn't.

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.


7. References

- RFC 1760: The S/Key One-Time Password System (Haller).