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.

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;

''

---

Vendor Information

737451

Filter by status: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

SSH Communications Security __ Affected

Updated: August 07, 2001

Status

Affected

Vendor Statement

According to SSH Communications Security’s advisory:

A potential remote root exploit has been discovered in SSH Secure Shell 3.0.0, for Unix only, concerning accounts with password fields consisting of two or fewer characters. Unauthorized users could potentially log in to these accounts using any password, including an empty password. This affects SSH Secure Shell 3.0.0. This is a problem with password authentication to the sshd2 daemon. The SSH Secure Shell client binaries (located by default in /usr/local/bin) are not affected. As SSH Secure Shell for Workstations on Unix only also includes a limited sshd2 server daemon, workstations are also vulnerable if the sshd2 daemon is running. SSH Secure Shell 3.0.1 fixes this problem for both Server and Workstation versions. Please note that if using a form of authentication other than password, AND password authentication is disabled, you are NOT VULNERABLE to this potential flaw.

A potential remote root exploit has been discovered in SSH Secure Shell 2.3 and 2.4, for HPUX in Trusted (TCB) Mode only, concerning accounts with password fields consisting of two or fewer characters. Unauthorized users could potentially log in to these accounts using any password, including an empty password. This affects SSH Secure Shell 2.3 and 2.4. This is a problem with password authentication to the sshd2 daemon. The SSH Secure Shell client binaries (located by default in /usr/local/bin) are not affected. As SSH Secure Shell for Workstations,on HPUX in Trusted (TCB) Mode only, also includes a limited sshd2 server daemon, workstations are also vulnerable if the sshd2 daemon is running.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

At the time of this writing, no Unix or Linux distributions are known to ship with SSH Secure Shell installed. However, certain distrubutions do utilize accounts with encrypted password fields that contain two or fewer characters. If SSH Secure Shell is installed on such a distribution (or encrypted password fields have been modified to contain two or fewer characters), and the distibution uses crypt() for password encryption, and SSH Secure Shell is configured to use password authentication, then the system will be vulnerable.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23737451 Feedback>).

OpenSSH __ Not Affected

Updated: July 25, 2001

Status

Not Affected

Vendor Statement

“…we are 100% not affected.”

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23737451 Feedback>).

CVSS Metrics

Group	Score	Vector
Base
Temporal
Environmental

References

• <http://www.securityfocus.com/bid/3078&gt;
• <http://www.securitytracker.com/alerts/2001/Jul/1002063.html&gt;
• <http://www.ssh.com/products/ssh/exploit.cfm&gt;

Acknowledgements

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

This document was written by Art Manion.

Other Information

CVE IDs:	CVE-2001-0553
Severity Metric:	25.65 Date Public: