Fuzzing Like It’s 1989

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

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

  • 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