[22059] in bugtraq
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
daemon@ATHENA.MIT.EDU (Casper Dik)
Wed Aug 1 16:37:07 2001
Message-Id: <200108010837.KAA01807@romulus.Holland.Sun.COM>
To: Nate Eldredge <neldredge@hmc.edu>
Cc: Dale Southard <southard1@llnl.gov>, Dan Kaminsky <dankamin@cisco.com>,
Stephanie Thomas <customer.service@ssh.com>, bugtraq@securityfocus.com
In-reply-to: Your message of "Sun, 22 Jul 2001 06:14:25 PDT."
<Pine.LNX.4.21.0107220554010.24934-100000@odin.ac.hmc.edu>
Date: Wed, 01 Aug 2001 10:37:06 +0200
From: Casper Dik <Casper.Dik@Sun.COM>
>On 21 Jul 2001, Dale Southard wrote:
>
>> 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.]
>
>What's wrong with just using `strcmp' (i.e. no constraint at all)? After
>all, what you want to know is just whether the two strings are identical,
>period. And unless crypt() and /etc/shadow are both broken, it will stop
>at the right place. I realize it goes against the reflexive "only strn*
>functions are safe" idea, but that shouldn't substitute for thinking...
It does look a knee-jerk str* is bad, use strn* type of code change.
strcmp() is *never* dangerous. strncmp() is really only useful
for prefix checking and should not be introduced as part of "security fixes".
Casper
