• tl;dr sec
  • Posts
  • Lightning in a Bottle: 25 Years of Fuzzing

Lightning in a Bottle: 25 Years of Fuzzing

Richard Johnson describes the history of fuzzing, the primary types of fuzzing, modern tools and advancements, SDLC integration, and more.

Author

Clint Gibler
March 24, 2020

Richard Johnson, Dir. of Security Research, Oracle Cloud 
FuzzCon 2020 twitter, linkedin
🖥️ slides

Note: This is just a quickly done, mini summary- much useful content has been omitted. The talk has some great historical perspective and useful intro information if you’re new to fuzzing. This summary is intended to have some key takeaways assuming you’re already familiar with fuzzing.

For more info on fuzzing, see posts tagged fuzzing. For more detailed summaries, you can check out my mega summary of every AppSec Cali 2019 talk.

This was a FuzzCon 2020 keynote given by Richard Johnson, which occurred the week of RSA 2020 in a different venue. The title is likely a reference to Yan Shoshitaishvili’s DEF CON 2017 talk 25 Years of Program Analysis and Christina Aguilera’s InfoSec anthem, Genie In A Bottle.

This talk is an excellent intro and overview of fuzzing. Richard’s talk covers the history of fuzzing, from Professor Barton Miller’s lightning storm experience to early mutational and generational fuzzing, to AFL, 2016 Cyber Grand Challenge, desirable fuzzer features, fuzzing in the SDLC, libFuzzer, LLVM Address Sanitizer, and more.

Some interesting points of note:

  • About half of the exploitable vulnerabilities found in Chrome in 2019 were found in code less than a year old.

  • 40% of OSS-Fuzz bug finds were new check-ins before code shipped to stable

  • BlackHat EU 2019 slides: ClusterFuzz: Fuzzing at Google Scale

When deployed effectively, security automation will generate a large amount of data that requires expert engineering attention.

Typically, developers are initially flooded with results when fuzzing first begins. This can create resistance and should be taken into consideration in late-stage adoption of fuzzing and setting expectations around remediation.

Ideally developers will work with security engineers to iterate on their fuzzing harnesses until they are adequate and then security engineers will perform initial triage.

There are currently 2 approaches for automating triage:

  • Divide and conquer brute force: Locate a code check-in that introduced the bug or minimize an input (inefficient and imprecise)

  • Dataflow analysis and taint tracking: Determine precise instruction flow leading to crash, heuristics can suggest a patch location (Complex and new technology)

While the context here is about fuzzing, I think the same lessons apply for integrating continuous lightweight static and dynamic analysis tooling into CI/CD.