
Fuzzing Like It’s 1989 - ploggingdev
https://blog.trailofbits.com/2018/12/31/fuzzing-like-its-1989/
======
tyoma
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
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
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
Is nslookup from bind9 or some other package? I think ISC might be interested
in fixing the crash.

------
dane-pgp
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
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
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.

~~~
barrkel
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.

------
entwife
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.

------
ape4
Good article

