SkipNavigation
US-CERT
American Flag
  Vulnerability
Notes
Database

Search Vulnerability Notes

Vulnerability Notes Help Information


 
 View Notes By
  Name

ID Number

CVE Name

Date Public

Date Published

Date Updated

Severity Metric



 Other Documents
  Technical Alerts

Technical Bulletins

Alerts

Security Tips

Vulnerability Note VU#737451

SSH Secure Shell sshd2 does not adequately authenticate logins to accounts with encrypted password fields containing two or fewer characters

Overview

A vulnerability exists in SSH Secure Shell that allows an intruder to log to an account which contains a stored encrypted password of two or fewer characters in length. An intruder may leverage the privileges of such an account to gain full control of the system.

I. Description

Certain Unix and Linux systems ship with accounts containing two or fewer characters in the encrypted password field. For example, /etc/passwd or /etc/shadow might contain an entry similar to this:

    nobody:!!:11121:0:99999:7:::


Login to this account is meant to be disabled, as "!!" in the encrypted password field does not correspond to the 13 character hash produced by crypt().

When configured to use password authentication, SSH Secure Shell 3.0.0 sshd2 calls the crypt() function with the password entered by the user and a salt value as arguments: crypt(password, salt). The salt value is the first two characters of the encrypted password stored in /etc/passwd or /etc/shadow. The crypt() function returns a 13 character hash, with the first two characters of the hash being the salt value, which is the first two characters of the encrypted password. sshd2 then calculates the length of the encrypted password as two characters, and compares the first two characters of the encrypted password with the first two characters of the hash returned by crypt(). Since the first two characters of the results of crypt() are the salt, which was obtained from the first two characters of the encrypted password, the comparison is successful and the user is authenticated.

SSH Secure Shell using password authentication on a system that has accounts containing two or fewer characters in the encrypted password field is vulnerable under the following circumstances:
  • SSH Secure Shell 3.0.0 on any Unix or Linux system that uses crypt() for password encryption is vulnerable.
  • SSH Secure Shell 2.3 and SSH Secure Shell 2.4 on HP-UX 10.20 and HP-UX 11.00 systems running in TCB mode are vulerable.

Operating systems that do not use the crypt() hash function for password encryption are not vulnerable.

II. Impact

Intruders can gain elevated privileges which they may leverage into root access. According to SSH Communications Security's advisory:

    Some stock machines which have default locked accounts running SSH Secure Shell 3.0 become vulnerable to arbitrary logins. This is a serious problem with Solaris, for example, which uses the sequence "NP" to indicate locked administrative accounts such as "lp", "adm", "bin" etc. Some Linux machines which have accounts with !! in the etc/passwd or /etc/shadow such as xfs or gdm are also vulnerable. Since it is relatively easy to become root after gaining access to certain accounts, we consider this a potential root exploit.

III. Solution

SSH Communications Security recommends that customers upgrade to SSH Secure Shell 3.0.1 or later.

Alternative solutions provided in SSH Communications Security 's advisory include the following:

Disable password authentication to the SSH Secure Shell daemon (sshd2) in the /etc/ssh2/sshd2_config and use another form of authentication such as public key, SecurID, Kerberos, certificates, Smart Cards, or hostbased to authenticate your users.

If you cannot disable password authentication fully, limit access to the sshd2 daemon to allow only users with entries in the /etc/passwd and /etc/shadow which exceed two characters. This can be done using the AllowUsers, AllowGroups, DenyUsers, DenyGroups keywords in the /etc/ssh2/sshd2_config file.

Assign a valid password for each account. Because it is possible that assigning a password to some system accounts could cause problems on some operating systems, this work-around is limited and is provided only as a last-resort alternative.

Use the following patch in the source code:


    '''

    File /lib/sshsession/sshunixuser.c
    Function ssh_user_validate_local_password
    Location near line 953, before
    /*Authentication is accepted if
    the encrypted passwords are identical. */
    Add lines

    if (strlen(correct_passwd) < 13)
    return FALSE;

    ''

Systems Affected

VendorStatusDate NotifiedDate Updated
OpenSSHNot Vulnerable25-Jul-2001
SSH Communications SecurityVulnerable7-Aug-2001

References


http://www.securityfocus.com/bid/3078
http://www.securitytracker.com/alerts/2001/Jul/1002063.html
http://www.ssh.com/products/ssh/exploit.cfm

Credit

The CERT Coordination thanks SSH Communications Security for information used in this document..

This document was written by Art Manion.

Other Information

Date Public:2001-07-20
Date First Published:2001-07-24
Date Last Updated:2001-10-25
CERT Advisory: 
CVE-ID(s):CAN-2001-0553
NVD-ID(s):CAN-2001-0553
US-CERT Technical Alerts: 
Metric:25.65
Document Revision:43

If you have feedback, comments, or additional information about this vulnerability, please send us email.
 

 
Page Corner Image
Copyright 2001 Carnegie Mellon University
Disclaimers and copyright information
Get Adobe Reader Get Adobe Reader