Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0

[Dale Southard <southard1 () llnl gov>]

"Dan Kaminsky" <dankamin () cisco com> writes:

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

Actually, I don't think it is nearly that complex...

On systems that use the standard unix crypt(), that function always
returns a 13 character string (a 2 character salt followed by an 11
character hash).  When a user tries to login, the system gets the 2
character salt from the password file and a password from the user,
and then runs those through crypt() and compares the 13 character
result to the hash string in the password file.  If they match, he/she
is authenticated.

Things like ``!!'', ``NP'', ``*LK*'' in the password file do not need
to have to have any special meaning to the OS other than the fact that
they are not 13 characters and thus will never match the output of
crypt().

Sshd should probably be constraining its match to the length of the
crypt() output rather than the length of the password file entry.  [I
say ``probably'' here because some systems (AIX) seem to produce null
password file hashes when `passwd` is given a null password.  If that
behavior is due to the underlying crypt() function, then the
``probably'' suggestion I just made yields remote root on those
systems.]

Systems that use md5 or blowfish for password hashing do something
different.   :-) :-)

-- 

/*  Dale Southard Jr.       southard1 () llnl gov        925-422-1463  */
/*  Computer Scientist, Accelerated Strategic Computing Initiative  */
/*  L-550,  Lawrence Livermore National Lab,  Livermore CA   94551  */
/*  AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving  */