Microsoft is dedicated to working with the community and our customers to continuously improve and tune our platform and products to help defend against the dynamic and sophisticated threat landscape. Earlier this year, we announced that we would replace the existing software testing experience known as Microsoft Security and Risk Detection with an automated, open-source tool as the industry moved toward this model. Today, we’re excited to release this new tool called Project OneFuzz, an extensible fuzz testing framework for Azure. Available through GitHub as an open-source tool, the testing framework used by Microsoft Edge, Windows, and teams across Microsoft is now available to developers around the world.
Fuzz testing is a highly effective method for increasing the security and reliability of native code—it is the gold standard for finding and removing costly, exploitable security flaws. Traditionally, fuzz testing has been a double-edged sword for developers: mandated by the software-development lifecycle, highly effective in finding actionable flaws, yet very complicated to harness, execute, and extract information from. That complexity required dedicated security engineering teams to build and operate fuzz testing capabilities making it very useful but expensive. Enabling developers to perform fuzz testing shifts the discovery of vulnerabilities to earlier in the development lifecycle and simultaneously frees security engineering teams to pursue proactive work.
Microsoft’s goal of enabling developers to easily and continuously fuzz test their code prior to release is core to our mission of empowerment. The global release of Project OneFuzz is intended to help harden the platforms and tools that power our daily work and personal lives to make an attacker’s job more difficult.
Recent advancements in the compiler world, open-sourced in LLVM and pioneered by Google, have transformed the security engineering tasks involved in fuzz testing native code. What was once attached—at great expense—can now be baked into continuous build systems through:
- Crash detection, once attached via tools such as Electric Fence, can be baked in with asan.
- Coverage tracking, once attached via tools such as iDNA, Dynamo Rio, and Pin can be baked in with sancov.
- Input harnessing, once accomplished via custom I/O harnesses, can be baked in with libfuzzer’s LLVMFuzzerTestOneInput function prototype.
These advances allow developers to create unit test binaries with a modern fuzzing lab compiled in: highly reliable test invocation, input generation, coverage, and error detection in a single executable. Experimental support for these features is growing in Microsoft’s Visual Studio. Once these test binaries can be built by a compiler, today’s developers are left with the challenge of building them into a CI/CD pipeline and scaling fuzzing workloads in the cloud.
Project OneFuzz has already enabled continuous developer-driven fuzzing of Windows that has allowed Microsoft to proactively harden the Windows platform prior to shipment of the latest OS builds. With a single command line (baked into the build system!) developers can launch fuzz jobs ranging in size from a few virtual machines to thousands of cores. Project OneFuzz enables:
- Composable fuzzing workflows: Open source allows users to onboard their own fuzzers, swap instrumentation, and manage seed inputs.
- Built-in ensemble fuzzing: By default, fuzzers work as a team to share strengths, swapping inputs of interest between fuzzing technologies.
- Programmatic triage and result deduplication: It provides unique flaw cases that always reproduce.
- On-demand live-debugging of found crashes: It lets you summon a live debugging session on-demand or from your build system.
- Observable and Debug-able: Transparent design allows introspection into every stage.
- Fuzz on Windows and Linux OSes: Multi-platform by design. Fuzz using your own OS build, kernel, or nested hypervisor.
- Crash reporting notification callbacks: Currently supporting Azure DevOps Work Items and Microsoft Teams messages