[NETWORK-SECURITY] SSH 3.0 Vuln.
Jiva DeVoe
plug-discuss@lists.PLUG.phoenix.az.us
Sat, 21 Jul 2001 15:50:08 -0700
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