> 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
This archive was generated by hypermail 2b30 : Fri Jul 20 2001 - 19:54:01 PDT