Fuzzing Like It’s 1989

Post by tyoma » Mon, Dec 31, 2018, 6:58 PM UTC

anonymouzz wrote: post #4

tyoma wrote: post #3

Author here. The predictions and insights from the two papers were fascinating to read with 30 years of hindsight. I also ran the random input generating “fuzz” tool against everything in /usr/bin (after some very minor fixes to get fuzz to build using ANSI C89). I can post the results later if there is interest.

I'd be interested. The two still offending tools (spell and f77) sound super rarely used these days. I think it's fair to compare samples of commonly used tools in 1995 with samples of commonly used tools in 2018 even if those samples are widely different. This would be more related to the change in the probability that an average user sees a crash.

  /usr/bin/icontopbm
  /usr/bin/pnmmontage
  /usr/bin/pnmpsnr
  /usr/bin/rletopnm
  /usr/bin/nslookup
  /usr/bin/aleph
  /usr/bin/acpi_listen
  /usr/bin/info
  /usr/bin/xetex

Post by barrkel » Mon, Dec 31, 2018, 7:17 PM UTC

wolf550e wrote: post #9

freedomben wrote: post #8

The real bomb-shell here that I find terrifying, is that there is still an open and (likely) exploitable bug in glibc that has been around for years and isn't getting attention. glibc is everywhere and used by almost everything . If you program in almost any modern language like ruby, node.js, python, java, C, C++, or more, you are calling functions in glibc. Note: Unless you use an alternative libc implementation su…

Golang infamously tried to not use libc at all and just use the kernel syscalls by itself. I think they now do use some stuff from glibc? Or maybe they only use the libc on OSes where the kernel interface is not stable, like Windows? Also, I don't know how much of glibc is used by openjdk, but potentially not a lot because the jvm wants to behave the same on all platforms, so they don't want to rely on behaviors of t…

Post by freedomben » Mon, Dec 31, 2018, 8:27 PM UTC

wolf550e wrote: post #9

freedomben wrote: post #8

The real bomb-shell here that I find terrifying, is that there is still an open and (likely) exploitable bug in glibc that has been around for years and isn't getting attention. glibc is everywhere and used by almost everything . If you program in almost any modern language like ruby, node.js, python, java, C, C++, or more, you are calling functions in glibc. Note: Unless you use an alternative libc implementation su…

Golang infamously tried to not use libc at all and just use the kernel syscalls by itself. I think they now do use some stuff from glibc? Or maybe they only use the libc on OSes where the kernel interface is not stable, like Windows? Also, I don't know how much of glibc is used by openjdk, but potentially not a lot because the jvm wants to behave the same on all platforms, so they don't want to rely on behaviors of t…

Post by fanf2 » Tue, Jan 01, 2019, 6:41 AM UTC

tyoma wrote: post #11

anonymouzz wrote: post #4

Earlier quoted context omitted.

I'd be interested. The two still offending tools (spell and f77) sound super rarely used these days. I think it's fair to compare samples of commonly used tools in 1995 with samples of commonly used tools in 2018 even if those samples are widely different. This would be more related to the change in the probability that an average user sees a crash.

This was on Ubuntu 14.04 -- I know 14.04 is dated, but its the last image I had running from the previous tests :). I wrote some stupidly simple bash to just pipe output of fuzz to every executable in /usr/bin/, with a 10 second timeout. This was only meant as a quick experiment, so there was no consideration of proper arguments (e.g. some applications may only read files and not stdin). The following applications pr…