|
|
Info |
Last Modified |
| 7 months ago |
|
|
|
|
Description |
Ssh.com's SSH Communications software contains a flaw that may allow a malicious user to log in to any account with a short password without needing to authenticate. The issue is triggered when the account has a password that is two characters or shorter. It is possible that the flaw may allow improper logins, resulting in a loss of confidentiality.
|
|
Classification |
Location:
Local Access Required,
Remote/Network Access Required
Attack Type:
Authentication Management,
Input Manipulation,
Misconfiguration
Impact:
Loss of Confidentiality
Exploit:
Exploit Available
Disclosure:
OSVDB Verified
|
|
Technical |
Many Unix and Linux systems are configured by default with system accounts containing two or fewer characters in the encrypted password field in /etc/passwd or /etc/shadow. This is intended to disable the account, since two characters does not correspond to the 13 character hash produced by crypt() as for a legitimate password. When configured to use password authentication, sshd2 in SSH Secure Shell 3.0.0 calls the crypt() function with the password entered by the user and a salt value. Unfortunately, the chosen salt is the first two characters of the encrypted password stored in /etc/passwd or /etc/shadow. crypt() returns a 13 character hash, with the first two characters of the hash being the salt value. sshd2 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(). Therefore, the salt is essentially checked against itself, the comparison is always successful, and the user is authenticated.
|
|
Solution |
Upgrade to version 3.0.1 or higher, as it has been reported to fix this vulnerability. It is also possible to correct the flaw by implementing the following workaround(s):
Apply the vendor-supplied patch.
Disable password authentication and use another supported form of authentication (public key, SecurID, Kerberos, certificates, Smart Cards, host-based).
Limit access to the sshd2 daemon to users with entries in the /etc/passwd and /etc/shadow which exceed two characters, by using the AllowUsers, AllowGroups, DenyUsers, and DenyGroups keywords in the /etc/ssh2/sshd2_config file.
Assign a valid password of more than two characters for each account. Assigning a password to some system accounts can cause problems on some operating systems, so this workaround is not recommended by the vendor.
SSH Secure Shell 3.0.0 on any Unix or Linux system that uses crypt() for password encryption is vulnerable. This includes most Unix and Linux systems. 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 also vulerable. Any operating system that does not use the crypt() hash function for password encryption is not vulnerable.
|
|
Products |
|
SSH Secure Shell for Unix
 |
2.3.x |
2.4.x |
3.0.0 |
|
|
|
|
|
|
Credit |
- Andrew Newman - newman-andy
 yale.edu - Yale University
- anonymous system administrator - Helsinki University of Technology
|
|
BlogsProvided by Technorati
|
None found at this time
|
|
|
