Skip to content
This repository was archived by the owner on Jan 20, 2020. It is now read-only.

Background

Jump to bottom
Everest Stefan Munro-Zeisberger edited this page May 3, 2018 · 1 revision

🔍 Overview

Fuzzers like AFL and GoFuzz are amazing pieces of security engineering, but were clearly built to be run in an ad-hoc way. Some other attempts to help alleviate this problem exist (like afl-fuzz-docker and Cloudfuzzer), but here at Coinbase we needed something that would scale within AWS to suit our needs and not create lots of extra busywork for developers.

Taking some cues from ClusterFuzz, we built MaxFuzz - a fuzzing framework that abstracts the annoying and tedious bits of running a fuzzing campaign away and makes it easy to deploy fuzzers and collect results.

❓Fuzzing

What is fuzzing?

Fuzzing is a method of automated software testing that involves continuously providing random, unexpected or invalid data to software with the aim of uncovering hard-to-detect bugs.

For a more detailed description, check out the OWASP Fuzzing Page.

Why fuzz?

Fuzzing can uncover the kind of bugs that aren't as easily found through code inspection, static analysis, or standard integration & unit testing. Specifically, fuzzing is great at finding security-oriented bugs that have the potential to leak data, or allow running of malicious code.

For some examples of interesting bugs fuzzing has caught, check out the AFL trophy list and the Gofuzz trophy list.

🥅 Goals

Maxfuzz provides an easily-deployable package that allows for self-contained fuzzer instrumentation, management and crash handling. Its goal is to make fuzzers like AFL and Gofuzz as easy to orchestrate and manage as any other part of software infrastructure.

Maxfuzz's goals/requirements/features are:

  1. Docker-deployable fuzzers: Fuzzers like AFL are great at fuzzing but can't be simply deployed and managed like most web frameworks. Maxfuzz takes care of all the legwork behind making these deployable.

  2. Easy file management: Fuzzers tend to dump crashers and output in a directory and leave the management to the user. Maxfuzz takes these crashes and either drops them in a local directory, or makes them accessible via S3. Goal: crasher categorization based on estimated severity.

  3. Parseable logging: Output from fuzzers is generally unstructured. Maxfuzz attempts to standardize fuzzer output and logs JSON for parseability.

  4. Crash reproduction: Maxfuzz attempts/should attempt to reproduce crashes, and save the crash output, which saves time when deciding what bug to attend to first.

Clone this wiki locally