[Cryptography] Buffer overflows from 1974

[Dennis Hamilton]

-----Original Message-----
From: Peter Gutmann via cryptography
Sent: Sunday, January 4, 2026 17:53
To: cryptography at metzdowd.com; hbaker1 at pipeline.com
Subject: Re: [Cryptography] Buffer overflows from 1974

Henry Baker <hbaker1 at pipeline.com> writes:

>It would be interesting to see if some of the new (claimed-to-be-safer) 
>variants of C would complain at compile-time about this old code.

It was written on a PDP-11... I'm guessing 45 with 32KW memory using ed on a Model 33 teletype, it couldn't run anything beyond the most basic pre-K&R C.

-----Reply-----
That's amazingly far from contemporary Standard C.  It predates K&R (1978) and smells more like RATFOR (of course).  It won't compile as-is with any modern compiler.  (Side issue: The code also assumes that a stored
Encrypted root password will not exceed 100 characters, including the final '\0' - the article didn't catch that one, to be fussy about it.)

Claimed-to-be safer C variants are mainly about extended provisions in the standard libraries to include checking.  These don't prevent creating that bug, but provide alternative API functions that incorporate checks
and fail safely *when*used*correctly*.  It takes discipline and probably successive generations of programmers to employ them consistently or at least habitually. TANSTAFL

There are always ways to write programs that fail badly and considering the nature of C (and hence C++), there's no commonly-used means to catch them all so long as the hardware instruction model is typical.  Turing wins 😊.

Whether a contemporary compiler provides cautions about the suspect code for `sudo` is a different matter and is an empirical question.  

KITCHEN SCIENCE:

I derived a pruned version of the defective one just to include the I/O, character operations, and the defect (and look Ma, no gotos).  

I used *maximum*warnings* (something folks unfortunately tend to turn off as nagging rather than addressing them) using VC/C++ build tools.  Because of that vigilance I received a warning about getchar() returning an int, not a char.  That's because an EOF can be returned and needs to be checked for.  I don't know if that was true in 1974 though.  If so, the published bug description missed that additional precaution.

The "more-secure" way I then substituted isn't new at all.  It is in K&R.  It involves using a single fgets() in place of the getchars() loop.  The fgets() takes a parameter for the size of the password[] array that the input is delivered into.  It is possible to determine that there is further input, although the password[] size is never exceeded.   I didn't bother addressing that, though I do in code of my own.