Note: this is only for those of you out there who paid for your ssh.
Those using OpenSSH are not affected.

On Sat, Jul 21, 2001 at 01:22:40PM -0700, J.Francois wrote:
> Forwarded:
> 
> > From: Stephanie Thomas [mailto:customer.service@ssh.com] 
> > Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
> > 
> > 
> > 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.
> > 
> > Version: PGP 7.0.1
> > 
> > iQA/AwUBO1jNq9BQTPJLnwPSEQKmMQCeIOd7B30wubtA3p3hrAK61dZhn08AoIx+
> > kAzWH6o/mdL81W9TC4tJINgp
> > =2BQq
> > 
> 

-- 
Jiva DeVoe
VP Of Software Development
Opnix, Inc. - Thoughts rule the world - R. W. Emerson
GPG Fingerprint: 0A17 DF84 516A 1DC4 B837  FE6D 3128 41CD 97CB 4AA7