Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Stephanie Thomas (customer.servicessh.com)
Date: Fri Jul 20 2001 - 19:34:02 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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.

    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.


    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.

    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.


    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:

    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.


    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

    -----END PGP SIGNATURE-----