
An Empirical Study of the Reliability of Unix Utilities (1989) [pdf] - beefhash
http://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf
======
pjc50
The section "comments on the results" is well worth reading.

> All array references should be checked for valid bounds. This is an argument
> for using range checking full-time. Even (especially!) pointer-based array
> references in C should be checked. This spoils the terse and elegant style
> often used by experienced C programmers, but correct programs are more
> elegant than incorrect ones

~~~
ryanianian
This always seemed to me like a flaw in the standard C library - there was no
good/built-in true array type that held the array size and was incorporated
into stdlib functions (especially string functions).

I haven't done C in a while, but I lost track of how many times I had to
create `struct array` to ensure I always passed the `*` with its length - it
always felt like I was doing something wrong. Maybe I was. But the prevalence
of overflow errors that could be fixed by size-checking makes me think there's
something missing in the language or standard-libraries that could have helped
a lot for many years.

~~~
milesvp
From what I understand, much of what seems missing, and possibly broken in C
comes primarily from the vast number of platforms it supports. It's actually
surprisingly hard to build a language that supports both x86, and 4bit
microcontrollers, and everything in between. That extra couple of bytes
attached to an array with it's size is _huge_ for embedded systems.

~~~
ryanianian
Ya that was my intuition - C's always giving you enough rope to hang yourself
and everyone around you. But I also wonder how many arbitrary-length strings
are handled by embedded systems. Maybe don't define an `array` type with
length, but maybe one just for `char*` (string) that included size and all the
`str` functions used it, that would solve a huge number of exploits.

~~~
pjmlp
A PC running MS-DOS 3.3 (512KB) would be an embedded systems, micro-controller
for today's standards.

I never had an issue with a Turbo Pascal application size due to
string/arrays.

------
montrose
"The ability to overflow an input buffer is also a potential security hole, as
shown by the recent Internet worm."

Interesting data point that in 1989, it was still a novel idea that buffer
overflow was related to security.

~~~
pjmlp
Already in 1979 it was clear that C developers needed help to write proper
code.

> To encourage people to pay more attention to the official language rules, to
> detect legal but suspicious constructions, and to help find interface
> mismatches undetectable with simple mechanisms for separate compilation,
> Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which
> scanned a set of files and remarked on dubious constructions.

Dennis M. Ritchie, [https://www.bell-
labs.com/usr/dmr/www/chist.html](https://www.bell-
labs.com/usr/dmr/www/chist.html)

------
jepler
It's good to be reminded that the state of the art WRT program stability has
improved, though it's nearly 30 years later and things still aren't
"perfect"... also, I didn't realize "fuzzing" as a term was 30 years old.

~~~
maxxxxx
"I didn't realize "fuzzing" as a term was 30 years old."

When you read papers from the 60s, 70s and 80s it's amazing how many things we
think are new today have already been discussed back then.

~~~
pjmlp
Including safer systems programming.

[https://en.wikipedia.org/wiki/Burroughs_large_systems](https://en.wikipedia.org/wiki/Burroughs_large_systems)

