Software Engineering Institute

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.

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.

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;

''