I know a lot of people on this list use SSH, so this may be relevant. This exploit does not affect openSSH, or the commercially available versions SSH 2.3.x or SSH 2.4.x Kevin ----- Original Message ----- From: "Stephanie Thomas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 20, 2001 8:34 PM Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear Secure Shell Community, > > 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. > > SSH Secure Shell 3.0.1 fixes this problem. > > Please note that if using a form of authentication > other than password, AND password authentication > is disabled, you are NOT VULNERABLE to this issue. > > PLATFORMS IMPACTED: > > 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 > > Please note that other platforms not listed here > may also be vulnerable. > > PLATFORMS NOT IMPACTED: > > Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable. > > Please note that other platforms not listed here > may also be immune. > > SCOPE > > 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. > > DETAILED 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 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. > > SOLUTIONS > > Preferred > > Immediately upgrade to SSH Secure Shell 3.0.1 > which will be available on our e-commerce site > http://commerce.ssh.com shortly, and is available > on the ftp site now - ftp://ftp.ssh.com/pub/ssh > A patch for 3.0.0 source code is also available there. > > 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, 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. > > 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; > > "" > > We apologize for any inconvenience this may cause. > SSH Communications Security takes security issues very > seriously, and a CERT advisory and submission to Bugtraq > regarding this issue have been submitted. Please make > every effort to ensure that your systems are protected > using one of the above 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. While we may not be able to address each request > for information on this issue individually, we will > make publicly available any relevant information possible > which addresses your questions and concerns. > > 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. > > -----BEGIN PGP SIGNATURE----- > Version: PGP 7.0.1 > > iQA/AwUBO1jNq9BQTPJLnwPSEQKmMQCeIOd7B30wubtA3p3hrAK61dZhn08AoIx+ > kAzWH6o/mdL81W9TC4tJINgp > =2BQq > -----END PGP SIGNATURE----- > _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
