COMMAND

    SSH

SYSTEMS AFFECTED

    SSH 3.0

PROBLEM

    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.

    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.

    This vulnerability was found  and reported by an  anonymous system
    administrator  at  the  Helsinki  University  of Technology and by
    Andrew Newman of Yale University.

SOLUTION

    SSH Secure Shell 3.0.1 fixes  this problem.  Tru64 4.0.G,  NetBSD,
    and OpenBSD are not vulnerable.

    Immediately upgrade  to SSH  Secure Shell  3.0.1.   As 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.

    This only affects systems that use crypt() to validate  passwords.
    If you  use md5  or blowfish  instead (which  OpenBSD, NetBSD, and
    Debian  Linux,  among  others  do  by  default)  you should not be
    vulnerable.