[cobalt-security] Fw: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0

["Kevin D" <kdlists@xxxxxxxxxxxxxxx>]

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" <customer.service@xxxxxxx>
To: <bugtraq@xxxxxxxxxxxxxxxxx>
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-----
>