Fuzzing Like It’s 1989

Fuzzing Like It’s 1989(blog.trailofbits.com)

131 points by ploggingdev 7 years ago | 16 comments

tyoma 7 years 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 7 years 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 7 years 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

cat199 7 years 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

tyoma 7 years ago | | |

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

dane-pgp 7 years ago |

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.

freedomben 7 years 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.

tyoma 7 years ago | |

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.

wolf550e 7 years 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.

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

saagarjha 7 years ago | | |

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

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

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

ape4 7 years ago |

Good article