by redmail.netbsd.org with SMTP; 24 Jan 2000 22:56:51 -0000
	by noc.untraceable.net (8.10.0.Beta12/8.10.0.Beta12/bonk!) id e0OMunc13946
	for tech-security@netbsd.org; Mon, 24 Jan 2000 17:56:49 -0500 (EST)
Date: Mon, 24 Jan 2000 17:56:48 -0500
From: Andrew Brown <atatat@atatdot.net>
To: tech-security@netbsd.org
Subject: [harikiri@ATTRITION.ORG: S/Key & OPIE Database Vulnerability]
Message-ID: <20000124175648.A13877@noc.untraceable.net>
Reply-To: Andrew Brown <atatat@atatdot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Receipt-To: receipts@daemon.org

you've probably seen this, but how come netbsd isn't mentioned here?
openbsd and freebsd are mentioned in section 6:

> 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.

but netbsd is nowhere to be found.  i happen to know that -current is
fine and has been for over a year.

  Module Name:    src
  Committed By:   abs
  Date:           Wed Jan  6 06:08:37 UTC 1999

  Modified Files:
	src/etc: Makefile
  Log Message:
  Install /etc/skeykeys 600 - from PR6519 by andrew@untraceable.net, tested OK.

why do they always leave us out?

----- Forwarded message from harikiri <harikiri@ATTRITION.ORG> -----

Date:         Fri, 21 Jan 2000 19:15:20 -0600
Reply-To: harikiri <harikiri@ATTRITION.ORG>
From: harikiri <harikiri@ATTRITION.ORG>
Subject:      S/Key & OPIE Database Vulnerability
To: BUGTRAQ@SECURITYFOCUS.COM

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).
		Any Unix 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).

EOF

----- End forwarded message -----

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."