Vulnerability Note VU#737451

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

Original Release date: 24 Jul 2001 | Last revised: 25 Oct 2001

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.

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.

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.

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 (Learn More)

VendorStatusDate NotifiedDate Updated
SSH Communications SecurityAffected-07 Aug 2001
OpenSSHNot Affected-25 Jul 2001
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A

References

Credit

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

This document was written by Art Manion.

Other Information

  • CVE IDs: CAN-2001-0553
  • Date Public: 20 Jul 2001
  • Date First Published: 24 Jul 2001
  • Date Last Updated: 25 Oct 2001
  • Severity Metric: 25.65
  • Document Revision: 43

Feedback

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