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 <harikiriat_private> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:29:59 PDT