SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0

crossposto anche questo... stamattina non l'ho ancora visto su bugtraq... 

----- Original Message ----- 
From: Steve <steve@securesolutions.org>
To: <vulnwatch@vulnwatch.org>
Sent: Saturday, July 21, 2001 8:58 AM
Subject: [VulnWatch] URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0


> From: Stephanie Thomas [mailto:customer.service@ssh.com] 
> 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.



________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List