5 ms·

Fuzzing Like It’s 1989

131 points by ploggingdev 8y ago

ape4 8y ago
Good article
tyoma 8y ago
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.
- anonymouzz 8y ago
  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.
  - tyoma 8y ago
    Agree. Also a random input generation tool should really be run multiple times against each target, etc.
  - cat199 8y ago
    f77/f2c - you'd be surprised often gets pulled in if other fortran (gfortran usually on a linux) is not available when building certain numerical software which in turn relies on netlib.org open fortran code, which in turn is written in fortran77 these libraries are give-or-take at the core of tons of numerical/scientific computing software, and likely used by many other programs needing heavy math
    - a-dub 8y ago
      Translators are interesting here. In this case it looks like it's just falling during translation (and a fast failure at that). An interesting question would be if there were a structured input (ie; valid Fortran) that result in the emission of unsafe C.
  - tyoma 8y ago
    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 produced a core dump: /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
    - fanf2 8y ago
      Is nslookup from bind9 or some other package? I think ISC might be interested in fixing the crash.
dane-pgp 8y ago
The Debian discussion for the ul/glibc issue: https://lists.debian.org/debian-glibc/2016/09/msg00177.html https://lists.debian.org/debian-glibc/2016/09/msg00177.html mentions this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20632 https://sourceware.org/bugzilla/show_bug.cgi?id=20632 "This seems quite exploitable to me: we end up overwriting a function pointer that malloc invokes. If an attacker can invoke the process with stderr closed (easy to do from a shell), and can control what text the process outputs to stderr, the attacker can execute arbitrary code." If that's true, I can't help wondering if an exploit for this is already sitting in some blackhat's tool box somewhere.
freedomben 8y ago
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 such as musl, which is standard on things like Alpine Linux for example. However glibc is by far most common.
- wolf550e 8y ago
  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 the libc.
  - saagarjha 8y ago
    Go now calls through libSystem on macOS and iOS, at least: https://golang.org/doc/go1.11#runtime https://golang.org/doc/go1.11#runtime
  - barrkel 8y ago
    WinAPI for kernel32 is to Windows what libc is to POSIX, approximately. It's a lower level API than a language runtime and is more agnostic to language specifics, but is higher level than a kernel syscall interface.
  - freedomben 8y ago
    Going from memory here, and it's been a little while (< a year), but Go at least uses enough glibc that if you use certain functions it won't statically link on linux by default anymore, so I corroborate your statement :-) I ran into this when working on https://github.com/FreedomBen/findref https://github.com/FreedomBen/findref which is a command-line utility written in Go
- 8y ago
entwife 8y ago
Thanks. I read the Bart Miller papers for professional reasons late last year. It is very, very helpful to read contemporary discussion of this topic.

131 points by ploggingdev 8y ago

ape4 8y ago

Good article

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.

anonymouzz 8y ago
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.
- tyoma 8y ago
  Agree. Also a random input generation tool should really be run multiple times against each target, etc.
- cat199 8y ago
  f77/f2c - you'd be surprised often gets pulled in if other fortran (gfortran usually on a linux) is not available when building certain numerical software which in turn relies on netlib.org open fortran code, which in turn is written in fortran77 these libraries are give-or-take at the core of tons of numerical/scientific computing software, and likely used by many other programs needing heavy math
  - a-dub 8y ago
    Translators are interesting here. In this case it looks like it's just falling during translation (and a fast failure at that). An interesting question would be if there were a structured input (ie; valid Fortran) that result in the emission of unsafe C.
- tyoma 8y ago
  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 produced a core dump: /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
  - fanf2 8y ago
    Is nslookup from bind9 or some other package? I think ISC might be interested in fixing the crash.

dane-pgp 8y ago

The Debian discussion for the ul/glibc issue: https://lists.debian.org/debian-glibc/2016/09/msg00177.html https://lists.debian.org/debian-glibc/2016/09/msg00177.html mentions this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20632 https://sourceware.org/bugzilla/show_bug.cgi?id=20632 "This seems quite exploitable to me: we end up overwriting a function pointer that malloc invokes. If an attacker can invoke the process with stderr closed (easy to do from a shell), and can control what text the process outputs to stderr, the attacker can execute arbitrary code." If that's true, I can't help wondering if an exploit for this is already sitting in some blackhat's tool box somewhere.

freedomben 8y ago

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 such as musl, which is standard on things like Alpine Linux for example. However glibc is by far most common.

wolf550e 8y ago
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 the libc.
- saagarjha 8y ago
  Go now calls through libSystem on macOS and iOS, at least: https://golang.org/doc/go1.11#runtime https://golang.org/doc/go1.11#runtime
- barrkel 8y ago
  WinAPI for kernel32 is to Windows what libc is to POSIX, approximately. It's a lower level API than a language runtime and is more agnostic to language specifics, but is higher level than a kernel syscall interface.
- freedomben 8y ago
  Going from memory here, and it's been a little while (< a year), but Go at least uses enough glibc that if you use certain functions it won't statically link on linux by default anymore, so I corroborate your statement :-) I ran into this when working on https://github.com/FreedomBen/findref https://github.com/FreedomBen/findref which is a command-line utility written in Go
8y ago

entwife 8y ago

Thanks. I read the Bart Miller papers for professional reasons late last year. It is very, very helpful to read contemporary discussion of this topic.