"Dan Kaminsky" <dankaminat_private> 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. southard1at_private 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 */
This archive was generated by hypermail 2b30 : Sat Jul 21 2001 - 14:26:27 PDT