[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