Google goes 'fuzzy' to combat insecure software

Google's new OSS-Fuzz initiative tests key open source software projects at scale, so you won't have to

Google goes 'fuzzy' to combat insecure software
Michael Bentley

It may sound like something you do to a sweater, but “fuzzing”—testing applications against random input to detect potentially fatal errors—has become a major weapon in the arsenal against insecure software. Microsoft swears by it, and Mozilla has made use of it.

Google’s fond of it as well—so much so that it’s been developing, in conjunction with the Core Infrastructure Initiative, a fuzzing service for vital open source infrastructure projects.

Bring out your bugs

The new OSS-Fuzz program accepts projects that “have a large user base and/or be critical to Global IT infrastructure” for testing. Once a project has been accepted, any problems it discovers are reported as soon as they are found and are disclosed to the public 90 days after that, according to Google’s disclosure policy for third-party bugs. The code used for OSS-Fuzz is being made available as an open source project, but Google is mainly promoting OSS-Fuzz as a sponsored initiative.

Most of the OSS-Fuzz code, previously released as open source, falls into two camps. One is fuzzing systems that perform the actual fuzz testing on an executable for a project; LLVM’s libFuzzer is one such fuzzing system. The other is sanitizers—utilities that analyze the tested project’s source code for many common varieties of programmer mistakes, such as use-after-free errors or buffer overflows.

People are either going to love or hate one thing about the submission process: If you want to submit a project to OSS-Fuzz, you can’t merely point at a GitHub repository somewhere; you need to submit a Docker image of the project. Google’s rationale is that doing so “limits [Google’s] exposure to a multitude of Linux varieties and provides a reproducible and secure environment for fuzzer building and execution.”

Do it big or do it at home

The other rationale for using containers is that crating up the software this way makes it easier for Google to fulfill OSS-Fuzz’s goal of “combining modern fuzzing techniques with scalable distributed execution.” It’s far easier and more effective for Google to perform this kind of testing in parallel and at scale than it is for others to do it themselves. Project owners can rent a cloud by the minute and run Google’s own test suite against the applications, but Google’s betting most people would rather leave that work to others.

Microsoft has its own cloud-based, fuzz-testing service, dubbed Project Springfield, which it previewed earlier this year. Springfield, though, is intended as a for-pay, enterprise-class service. OSS-Fuzz provides free fuzz testing for the kinds of common infrastructure almost everyone is forced to use. It isn’t inconceivable, though, that Microsoft could provide its fuzz-testing service as a courtesy to select open source projects.

Copyright © 2016 IDG Communications, Inc.