Fuzzing Like It’s 1989
blog.trailofbits.com
Fuzzing Like It’s 1989
1–10 of 17 posts
Re: Fuzzing Like It’s 1989
#2Good article
Re: Fuzzing Like It’s 1989
#3Author 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.
Re: Fuzzing Like It’s 1989
#4Author 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.
Re: Fuzzing Like It’s 1989
#5Author 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.
Re: Fuzzing Like It’s 1989
#6Author 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.
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
Re: Fuzzing Like It’s 1989
#7The 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.
Re: Fuzzing Like It’s 1989
#8The 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.
Re: Fuzzing Like It’s 1989
#9The 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 the libc.
Re: Fuzzing Like It’s 1989
#10The 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…
Go now calls through libSystem on macOS and iOS, at least: https://golang.org/doc/go1.11#runtime