News

SSH strongly advises all users of Secure Shell 3.0.0 to upgrade immediately to Secure Shell 3.0.1

A potential remote root exploit has been discovered in SSH Secure Shell 3.0.0, for Unix only, concerning accounts with password field entries of two characters or less. 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. 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.

SSH Secure Shell 3.0.1 fixes this problem.

We apologize for any inconvenience this may cause. SSH Communications Security takes security issues very seriously, and a CERT advisory, submission to Bugtraq, and notification to customers regarding this issue have been distributed. Please make every effort to ensure that your systems are protected using one of the below methods as quickly as possible. As this information becomes widely known, your systems could be at even greater risk if appropriate measures are not taken.

SSH is fully committed to serving and supporting our users and products.

Please direct any questions to the following:

Commercial:
http://www.ssh.com/support/ssh/commercial_support.cfm

Evaluating:
http://www.ssh.com/support/ssh/pre-sales_support.cfm

Non-Commercial:
http://www.ssh.com/support/ssh/non-commercial_support.cfm

Please note that SSH cannot promise individual responses to non-commercial / educational users. We are fully committed to serving and supporting our users and products, and will make publicly available any relevant information possible which addresses your questions and concerns.

Below is the full description of the issue:

SSH Secure Shell 3.0.0 Potential Remote Root Exploit

Systems Affected

The following systems are known to have this issue when running SSH Secure Shell 3.0.0:

• Red Hat 6.2 Linux 6.1 thru 7.1
  
• Solaris 2.6 thru 2.8
  
• Caldera Linux 2.4
  
• Suse Linux 6.4 thru 7.0
  
• HPUX 10.20
  
• HPUX 11.00
  

This affects SSH Secure Shell 3.0.0. SSH Secure Shell 3.0.1 fixes this problem.

Overview

A potential remote root exploit has been discovered in SSH Secure Shell 3.0.0, for Unix only, concerning accounts with password field entries of two characters or less. 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.

I. Description

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 or the 3.0.0 daemon 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.

II. Impact

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.

III. Solutions

Preferred

Immediately upgrade to SSH Secure Shell 3.0.1 (available on our online store).

Alternative work-arounds

• 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. Please see our SSH Secure Shell support web pages for more information on how to enable these authentication methods.
  OR
  
  
• 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. See our SSH Secure Shell support web pages and man sshd2_config for more information.
  
  OR
  
  
• 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.
  
  OR
  
  
• 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;

''

IV. Credits

This vulnerability was found and reported by an anonymous system administrator at the Helsinki University of Technology and by Andrew Newman of Yale University.

© 2002 SSH Communications Security Corp. All rights reserved. ssh® is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions. All other names and marks are property of their respective owners.