TUCoPS :: Unix :: General :: ssh35.htm

COMMAND
 SSH
SYSTEMS AFFECTED
 SSH 3.0
PROBLEM
 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.
 Some stock machines which have default locked accounts running SSH
 Secure Shell 3.0 are 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.
 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.
 This vulnerability was found and reported by an anonymous system
 administrator at the Helsinki University of Technology and by
 Andrew Newman of Yale University.
SOLUTION
 SSH Secure Shell 3.0.1 fixes this problem. Tru64 4.0.G, NetBSD,
 and OpenBSD are not vulnerable.
 Immediately upgrade to SSH Secure Shell 3.0.1. As 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.
 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. See our
 SSH Secure Shell support web pages http://www.ssh.com/support/ssh
 and man sshd2_config for 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.
 This only affects systems that use crypt() to validate passwords.
 If you use md5 or blowfish instead (which OpenBSD, NetBSD, and
 Debian Linux, among others do by default) you should not be
 vulnerable.