SSH Secure Shell 3.0 vulnerability
by phiber on July 21st, 2001 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 for Unix only. 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.
Please note that if using a form of authentication
other than password, AND password authentication
is disabled, you are NOT VULNERABLE to this issue.
Systems affected:
Red Hat Linux 6.1 thru 7.1
Solaris 2.6 thru 2.8
HP-UX 10.20
HP-UX 11.00
Caldera Linux 2.4
Suse Linux 6.4 thru 7.0
+ some other platforms not listed here
Details:
During password authentication, if the field containing
the encrypted password in /etc/shadow, /etc/password,
etc. is two or less characters long, SSH 3.0.0 will
allow anyone to access that account with ANY password.
The bug is in the code that compares the result of calling
crypt(pw, salt) with the value of the encrypted password
in the /etc/shadow (or /etc/password) file. SSH Secure Shell
Server 3.0.0 does a bounded string compare bounded to the
length of the value stored in aforementioned file (2
characters in this case) against the return value of
crypt(). The return value of crypt() is 13 characters,
with the first two characters being the salt value itself.
The salt value used is the first two characters of the
encrypted password in /etc/shadow (or /etc/password). A
2 character string comparison between the 2 character
encrypted password in /etc/shadow, and the 13 character
crypt() return value, whose first two characters ARE the
2 characters from the password in /etc/shadow. The strings
match, and the 3.0.0 daemon then accepts the password, no
matter what is input.
Solution:
Immediately upgrade to SSH Secure Shell 3.0.1. Patches are here.
- 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. These alternative
authentication methods are NOT VULNERABLE. More information
- 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, and DenyGroups
keywords in the /etc/ssh2/sshd2_config file.
More information
- 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;
""
Workarounds:
From SSH advisory, download it here.
