SSH Secure Shell 3.0.0 for Unix Lets Remote Users Login to Certain Accounts Without Authentication
SecurityTracker Alert ID: 1002063|
SecurityTracker URL: http://securitytracker.com/id/1002063
(Links to External Site)
Date: Jul 21 2001
User access via network|
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes |
Version(s): 3.0.0 (for UNIX only)|
SSH warned of a vulnerability with SSH Secure Shell version 3.0.0 for Unix that grants remote users access to certain accounts without authorization.|
It is reported that some hosts that have default locked accounts and are running SSH Secure Shell 3.0 are vulnerable to arbitrary remote logins.
When a remote user attempts to login using SSH, if the field containing the encrypted password in the password file (e.g., /etc/shadow, /etc/password) is two characters or less, SSH will grant the user access to that account with any password.
The bug is reportedly in the code that compares the result of calling crypt(pw, salt) with the value of the encrypted password the password file. SSH performs a bounded string compare incorrectly bounded to the length of the value stored in aforementioned file (two 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 the password file. A two character string comparison between the two character encrypted password in the password file and the 13 character crypt() return value (whose first two characters are the two characters from the password file) will match. The SSH daemon then accepts the password, regardless of the password supplied by the remote user.
This is a problem on any host that may have certain locked administrative accounts such as "lp", "adm", "bin", etc. On some hosts, these accounts will have '!!' in the password file.
The vendor reports that Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable.
[Editor's Note: The vendor considers this to be a remote root vulnerability. However, the vulnerability itself does not yield root level access. Instead, a remote user can obtain user level access via this vulnerability.]
A remote user can access certain accounts via SSH without authentication.|
SSH Secure Shell 3.0.1 reportedly fixes this problem. See the Vendor URL. The fix is also available at: ftp://ftp.ssh.com/pub/ssh|
A patch for 3.0.0 source code is also available at the ftp site.
Vendor URL: commerce.ssh.com/ (Links to External Site)
|Underlying OS: Linux (Any), UNIX (Any)|
|Underlying OS Comments: 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; other platforms may also be vulnerable|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0|
-----BEGIN PGP SIGNED MESSAGE-----
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.
Red Hat Linux 6.1 thru 7.1
Solaris 2.6 thru 2.8
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.
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.
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.
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.
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.
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.
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.
Use the following patch in the source code:
Location near line 953, before
/*Authentication is accepted if the encrypted
passwords are identical. */
if (strlen(correct_passwd) < 13)
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.
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
-----END PGP SIGNATURE-----
Go to the Top of This SecurityTracker Archive Page