What’s the fuzz about? Microsoft unveils its latest security tool

Microsoft has added the ability to “fuzz” for a number of dangerous memory corruption flaws to its automated security testing service, Microsoft Security Risk Detection (MSRD).

Security fuzzing works by throwing millions of tweaked and permuted (fuzzed) input files at an application in the hope of triggering unexpected or hard to find bugs, and thereby highlighting security vulnerabilities.

Because it’s a “black box” technique, no access to source code is needed. The tester pokes and probes an application from the outside in the same way a hacker would, hoping to uncover weaknesses without a clear understanding of the application’s inner workings.

At the end, the tester gets to see precisely what state caused the problem.

However, fuzzing can be time-consuming, resource intensive and leave your development team chasing bugs that aren’t exploitable security vulnerabilities, so some developers skimp.

In 2015, Microsoft hatched its answer in the shape of Project Springfield, an Azure cloud testing service built around its own internal fuzzing tools with AI used to do the heavy lifting. Initially, this offered static source code analysis (examining code without running it), or “white box” fuzzing.

Now slowly emerging from beta as MSRD, the company keeps adding new capabilities, the latest of which is VulnScan, a tool that looks for five different types of memory corruption flaws using the black box approach.

This sounds a bit dry but a lot of security vulnerabilities have at their root these memory problems – buffer overflows being the obvious example – which fuzzing is good at finding. Adding this capability makes MSRD a lot more useful.

Do we know this kind of fuzzing works? And why the recent enthusiasm for it?

According to Microsoft UK’s Mateusz Krzywicki:

Over a 10-month period where VulnScan was used to triage all memory corruption issues for Microsoft Edge, Microsoft Internet Explorer and Microsoft Office products. It had a success rate around 85%, saving an estimated 500 hours of engineering time for MSRC engineers.

Microsoft is so flush about this it even includes a breakdown of how it was used to get to the bottom of the Chakra memory corruption vulnerability (CVE-2017-0134), disclosed in March.

Google is also a fuzzing fan, earlier this year talking up the success of its OSS-Fuzz project, claiming to have found 264 vulnerabilities in 47 open source projects.

So it works, and being a black box technique it can work just as well for the bad guys as it does for the good ones. For development teams that have had “start fuzzing” on their to do list for a while the emergence of cloud-hosted fuzzing tools on Azure and Google Compute Engine is both a solution to the resources problem and a wake up call to get on with it.

We don’t know how much MSRD will cost when the wrapper comes off the beta, but I assume it won’t be cheap. There’s no doubt fuzzing could be a sizeable business for Microsoft, helped along by its support for Linux.

It’s as if Microsoft has come full circle from the dark days of 2004, an era when its under-estimation of Windows XP’s security nearly sank Windows. That led to the Security Development Lifecycle (SDL), which laid the foundations for the emerging world of security tools and testing solutions packaged into cloud services.

Microsoft is still not a security company exactly but the advent of cloud fuzzing and the MSRD might yet make it some money from an area that once caused it huge pain.