Users login

Create an account »

JOIN XATRIX

Users login

Home » Hacking News » SSH Secure Shell 3.0 vulnerability

SSH Secure Shell 3.0 vulnerability

by phiber on July 21st, 2001 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.


Please note that if using a form of authentication
other than password, AND password authentication
is disabled, you are NOT VULNERABLE to this issue.


Systems affected:

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

+ some other platforms not listed here


Details:

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.


Solution:

Immediately upgrade to SSH Secure Shell 3.0.1. Patches are here.



    Workarounds:
  • 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. More information

  • 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.
    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:

    """
    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;

    ""



From SSH advisory, download it here.


Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.

Contact

Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »