Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0

["Dan Kaminsky" <dankamin () cisco com>]

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

Since on Solaris all the standard binaries(sh, ls, rm, etc.) are bin owned,
all systems with SSH-3.0 should be considered to be completely rootable by
even basic unix-aware attackers.  Worse, the nature of the SSH protocols is
that the exact version of the SSH server shows up upon initial connection to
the SSHD port.  This means a mass scan, combined perhaps with minor TCP
property analysis, will reveal both the vulnerable SSHD and the specific OS
whose accounts are to be attacked.

Mass SSH scanners are available; it may be worthwhile as an administrator to
search and cleanse your network before someone else does.  While you're at
it, watch for OpenSSH 2.2.0p2 in particular, as there apparently exist Linux
root exploits for that obscure deattack.c bug found several months ago.

The big issue here, of course, is not that sshd incorrectly checks the
cryptographic hash of an inadequately sized password but that it checks it
at all.  NP, as far as I know, specifically stands for No Password
(acceptable, *not* needed), and !! I believe has the same meaning for
Linux(! for "no").  SSHD has traditionally when possible directly tested its
passwords straight through most available interfaces, be them a raw password
file or a PAM call.  But when the SSHD checked the cryptography of NP or !!,
it failed to successfully parse the critical message in the password
database:  Let Nothing At All, No Matter What, In.

When such a message exists, it deserves immediate servicing.  They expected
the cryptography to fail; it was an implicit assumption that an explicit
security-critical demand would be serviced automatically.  The assumption
was incorrect, and now a reasonably major hole exists.

Yours Truly,

    Dan Kaminsky, CISSP
    http://www.doxpara.com