Fuzzing Like It’s 1989 | Hacker News Reader

Fuzzing Like It’s 1989

blog.trailofbits.com

131 pointsploggingdev16 comments

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.

Agree. Also a random input generation tool should really be run multiple times against each target, etc.

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

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.

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

Is nslookup from bind9 or some other package? I think ISC might be interested in fixing the crash.

The Debian discussion for the ul/glibc issue:

https://lists.debian.org/debian-glibc/2016/09/msg00177.html

mentions this bug:

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.

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.

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.

Go now calls through libSystem on macOS and iOS, at least: https://golang.org/doc/go1.11#runtime

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.

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 which is a command-line utility written in Go

While that does seem like a buried lede, I felt it wasn't my place to raise alarms about a 2 year old bug that may have been fixed.

The bug description certainly makes it sound very serious. If its not fixed in upstream, it at least seems fixed at the distribution level since Ubuntu 18.04 and newer don't suffer from the issue. Or if they do, it can't be reached via the same code in ul.

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.

Good article

Reply on news.ycombinator.com