|
|
|
Vulnerability Note VU#737451SSH Secure Shell sshd2 does not adequately authenticate logins to accounts with encrypted password fields containing two or fewer charactersOverviewA 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. DescriptionCertain 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:
Operating systems that do not use the crypt() hash function for password encryption are not vulnerable. II. ImpactIntruders can gain elevated privileges which they may leverage into root access. According to SSH Communications Security's advisory:
III. SolutionSSH 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: ''' 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
References
The CERT Coordination thanks SSH Communications Security for information used in this document.. This document was written by Art Manion.
If you have feedback, comments, or additional information about this vulnerability, please send us
email. |
||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||
Get Adobe Reader