In April of this year, Dmitry Vyukov released the first version of go-fuzz, a coverage-guided fuzz testing tool based on ideas from afl. With very little fanfare, he unleashed it on the Go standard library and started filing huge numbers of crashers and other bugs found via automated, randomized testing.
Fuzzing is testing code by feeding it random data. It dates back to to Professor Barton Miller’s work in late 1980s. In the 2000s, it was picked up by the security community, because it turned out that many of these crashes could be turned into code exploits. Coverage-guided fuzzing, like afl and go-fuzz do, use information gathered at run-time about which code paths were executed to determine if a random input was “interesting” and should be used as the seed for further random tests.
Any program dealing with user input should use fuzz testing to make sure it can deal with unexpected inputs gracefully. It’s especially suited to packages like file formats, serialization routines, and compression algorithms.
But even with the great success go-fuzz was having in finding issues in the Go standard library (probably some of the best tested and well reviewed Go code in existence), it seemed few other people were using it in their own projects.
At the beginning of July, Dmitry presented go-fuzz at Gophercon.
Leading up to the release Go 1.5, I launched a fuzz-a-thon. The idea was simple: Dmitry is doing his best to make the Go standard library robust. We, the community, need to do the same for our own packages. I tweeted every day reasons to use go-fuzz.
At the beginning of August, Filippo Valsorda posted an excellent account of using go-fuzz at CloudFlare. Filippo’s post (and his talk at GothamGo detailed other ways to use go-fuzz for randomized tests, not only to find inputs that make your program crash.
A few weeks later, I published my own simple walk-through of fuzzing and patching a simple file format library.
People are beginning to use it. More and more packages include fuzz tests. The go-fuzz trophy case contains almost 400 bugs.
Please fuzz your own code.
This is a post in the Advent 2015 series.
Other posts in this series:
- Dec 31, 2015 - 2015 Year in Review
- Dec 30, 2015 - 2D Game Libraries for Go
- Dec 29, 2015 - etcd: distributed key-value store with grpc/http2
- Dec 28, 2015 - vendor folder
- Dec 27, 2015 - Glow: Map Reduce for Golang
- Dec 26, 2015 - Symmetric API Testing
- Dec 25, 2015 - Lessons in Go Learned while Implementing SHIELD
- Dec 24, 2015 - Tiny Linux OSes with Go
- Dec 23, 2015 - Geographical data manipulation using go
- Dec 22, 2015 - Composable Pipelines Improved
- Dec 21, 2015 - Hydra: Run your own IAM service in <5 Minutes
- Dec 20, 2015 - Automi: Stream Processing Over Go Channels
- Dec 19, 2015 - Writing an SSH server in Go
- Dec 18, 2015 - Manage Dependencies Like Other Languages With Glide
- Dec 17, 2015 - Gopy
- Dec 16, 2015 - NATS: High Performance Messaging
- Dec 15, 2015 - Generate and Use Free TLS Certificates with Lego
- Dec 14, 2015 - test2doc: Generate Your API Docs
- Dec 13, 2015 - Go in a Yocto project
- Dec 12, 2015 - Composable command-line tools
- Dec 11, 2015 - Announcing GopherCon 2016
- Dec 10, 2015 - Reducing boilerplate with go generate
- Dec 09, 2015 - Hooking libc using Go shared libraries
- Dec 08, 2015 - Go in a Monorepo
- Dec 07, 2015 - goa: Untangling Microservices
- Dec 06, 2015 - Superdog
- Dec 05, 2015 - Go Fuzz
- Dec 04, 2015 - afero: A Universal Filesystem Library
- Dec 03, 2015 - Debugging Go programs with Delve
- Dec 02, 2015 - Working with Semantic Versions
- Dec 01, 2015 - Introduction
comments powered by Disqus