Fuzz in Your Language, Fuzzer, or Architecture

At ForAllSecure, we’re all about fuzzing and making it easier for customers to quickly fuzz and secure their applications. That’s why we’ve gone ahead and compiled a catalog of fuzz targets intended for Mayhem that’s written and compiled using several different languages (and architectures) like C/C++, Python, Go, Rust, Java, and many others! We’ve also added several choices for specifying which fuzzer engine to use, whether that’s the popular libFuzzer, honggfuzz, AFL, or even our own Mayhem for Code fuzzer.

In essence, we’ve provided a swiss army knife of fuzzing options to not only serve as a quick-and-easy reference point for users to get started with fuzzing in general but to also showcase Mayhem’s versatility for fuzzing several languages and architectures in tandem with specific fuzzer engines. This catalog of tutorial fuzzing targets also emphasizes the recommended workflow for compiling targets using Docker and fuzzing such containerized applications in Mayhem.

Vulnerability in Libarchive Threatens Many Linux Distributions

This summer, Google experts using the ClusterFuzz and OSS-Fuzz tools, discovered a dangerous bug in the Libarchive library, which is responsible for working with archives and compressed files. Libarchive is included by default with Debian, Ubuntu, Gentoo, Arch Linux, FreeBSD, and NetBSD, and the vulnerability allows an attacker to execute arbitrary code on a vulnerable machine. It is reported that Windows and macOS, which also include the library, are not vulnerable.

The bug received the identifier CVE-2019-18408 and allows the attacker to execute arbitrary code in the system using a specially created archive file. The problem can be exploited through a malicious file obtained from cybercriminals through local applications that use various Libarchive components in their work.

Beginning Fuzz Cycle Automation

Did someone say fuzzy?

Improving Testing and Fuzz Development with Coverage Analysis

In my previous post, we covered using bncov to do open-ended coverage analysis tasks to inform our testing. This time we’ll take a look at how to write better tests in the form of harness programs (also known as fuzz drivers, programs are written to exercise specific parts of the code) that we will use for fuzz testing.

The basic idea in both unit testing and fuzzing is that we want to thoroughly test our code to increase our confidence and get reassurance that it performs as expected in the face of unexpected inputs or scenarios. If we want to improve our confidence, we can add steps to exercise more of the code. With unit testing, this means writing more unit tests; with fuzzing, this means running the fuzzer longer, making a better starting corpus, or writing more harness programs. By leveraging coverage analysis, we can automate the presentation of results from fuzzing to assist us in a roughly iterative approach and get more out of our fuzzing: