Date: Fri, 21 Jan 2000 19:15:20 -0600
From: harikiri <harikiri@ATTRITION.ORG.>
To: [email protected]Subject: S/Key & OPIE Database Vulnerability
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
