[Cryptography] Buffer overflows from 1974
Craig B Agricola
craig at theagricolas.org
Tue Jan 6 02:31:12 EST 2026
Peter Gutmann wrote:
> Today, but not in 1974. In 1974 a real programmer would have fixed it by
> saying "your fault for entering a stupidly long password, and in any case what
> are you going to achieve with that, it'll just segfault and you'll have to run
> it again, this time with valid input".
Except that the particular buffer overflow there is actually trivial to
exploit. No need to craft an executable payload to insert into your
input and then orchestrate a return into that code. Because pwbuf[]
*is* immediately after password[], you can overwrite the hash that has
been read from /etc/passwd by getpw(). Since you can trivially use the
passwd command to change your own password and observe the hash in
/etc/passwd, all you have to do is pad your password out to 100
characters (all but the first 7 characters are ignored by that version
of crypt()), pad out another 5 characters for the "root:" prefix of the
/etc/password line, add your known hash, and finish it with a ":"
(because that's how the implementation of su.c makes sure that the
hashes are the same length).
So, for instance, this password will work:
"abcdefghxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5WWWWWWW:"
(Yes, I recreated the unixV4 system per http://squoze.net/UNIX/v4/README
and confirmed it worked on a freshly installed system from the .tap
file.)
Since it's a trivial privilege escalation from any user to root, and
it's pretty obvious from simple code inspection (which was included in
/usr/source/s2/su.c), I can't imagine that it wasn't spotted (and likely
used) at the time, even if for nothing more than a party trick.
-Craig
More information about the cryptography
mailing list