4 ms·

An Empirical Study of the Reliability of Unix Utilities (1989) [pdf]

58 points by beefhash 9y ago

jepler 9y ago
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.
- nickpsecurity 9y ago
  I remember someone saying in another article they did it in the 1950's by taking piles of punch cards out of the trash to run through programs. Probably earliest example.
- simplicio 9y ago
  Barton Miller (one of the authors of the linked pdf) coined the term (though I'm sure the practice predates him.)
- maxxxxx 9y ago
  "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 9y ago
    Including safer systems programming. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems
pjc50 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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.
    - earenndil 9y ago
      But why not add such capabilities in the standard library and not use them in code running on 4-bit microcontrollers? That's sort of similar to what c11 is doing with its 'safe' variants on stdlib string functions.
montrose 9y ago
"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 9y ago
  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

58 points by beefhash 9y ago

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.

nickpsecurity 9y ago
I remember someone saying in another article they did it in the 1950's by taking piles of punch cards out of the trash to run through programs. Probably earliest example.
simplicio 9y ago
Barton Miller (one of the authors of the linked pdf) coined the term (though I'm sure the practice predates him.)
maxxxxx 9y ago
"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 9y ago
  Including safer systems programming. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems

pjc50 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
  - earenndil 9y ago
    But why not add such capabilities in the standard library and not use them in code running on 4-bit microcontrollers? That's sort of similar to what c11 is doing with its 'safe' variants on stdlib string functions.

montrose 9y ago

"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 9y ago
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