Exploit mitigation can only go so far
Microsoft’s security strategy is paying dividends by making it more costly and difficult for hackers to develop reliable exploits.
Matt Miller, a security software engineer in Microsoft’s Security Response Center (MSRC), provided this insight during a well-received presentation at the BlueHat IL security conference in Israel last week.
Slides from the talk – which covered trends, challenges, and strategic shifts in the software vulnerability landscape – provide the most comprehensive overview of Redmond’s security strategy, as seen from the front line of vulnerability response.
Miller, who worked as a core contributor to the Metasploit framework prior to joining Microsoft, provided a 20-year run-through, covering long-term trends in the software vulnerability mitigation landscape during a data-packed presentation (PDF).
Damage control
Microsoft’s multi-pronged vulnerability response strategy over the last 10 years or so has focused not just on quashing security bugs, but on breaking exploitation techniques and on containing damage and preventing persistence.
In addition, Microsoft has sought to limit the window of exploitation if all else fails, Miller said.
This more mature approach to vulnerability mitigation recognizes that focusing on eliminating bugs alone is never going to be successful.
Although the number of bugs addressed by Microsoft every year is growing, the number of security flaws that give rise to an exploit has fallen steadily year after year since a peak in 2010, Miller’s data revealed.
If a vulnerability is exploited, it is most likely to be exploited either as a zero-day or as part of a targeted attack.
This has led criminal hackers to put greater reliance on attacks featuring elements of social engineering, such as phishing, tech support scams, and the use of macros to trick users into open booby-trapped files.
Shifting threat landscape
Widespread attacks are now the exception rather than the norm, according to Miller.
Worms like Nimda and Sasser are no longer a regular occurrence, thanks to various mitigation technologies introduced by Microsoft over the years, supplemented more recently by improved sandboxing technologies.
These technologies have included turning Windows XP’s built-in firewall on by default, introducing Protected View in Office products, Data Execution Prevention (DEP), and Address Space Layout Randomization (ASLR – a memory corruption defense).
Security bugs still crop up from time to time, and Miller’s presentation cataloged the root cause of vulnerabilities patched by Microsoft over the past 12 years. A large majority (around 70%) stem from “memory safety” issues, he said.
The root cause of CVEs (software vulnerabilities) exploited within 30 days of a patch skews towards ‘use after free’ and ‘heap corruption’ issues. Buffer overruns – an old favorite in exploit development – have decreased in utility, as out-of-bounds read/write issues have become more important.
That being said, Miller noted that most of the vulnerability classes that existed more than 20 years ago still exist today. In addition, new vulnerability classes – such as the speculative execution side-channel vulnerabilities associated with Spectre and Meltdown – have arisen.
This makes it harder to eliminate vulnerabilities by writing more secure code – emphasizing the importance of the defense in depth approach taken by Microsoft that involves breaking exploitation techniques and reducing the attack surface of apps and services, among other strategies.
Strategic shifts
Miller concluded that secure development techniques will mature in a manner that helps minimize the problems posed by software vulnerabilities.
The goal is to make software updates infrequent and easy to apply, while making it more difficult – and therefore costly – for hackers to develop reliable exploits.
In practice, this means clamping down on common classes of memory safety vulnerabilities, moving developers onto using safer programming languages (such as Rust and C# instead of C++), as well as making software development more secure and cost effective more generally.
Even if vulnerabilities are minimized as a threat, other infosec problems will remain including social engineering attacks, credential stuffing, physical tampering, and more, Miller was careful to note in concluding his talk.
The security engineer’s presentation was warmly received by various security experts including Ben Hawkes, Google Project Zero team lead.
“There is a level of acknowledgement on the limits of exploit mitigations here that I haven't seen from Microsoft in the past, and the resulting ‘strategic shifts’ look very positive,” Hawkes said in a Twitter thread.
“In the browser at least, the technological advance of exploit mitigations has stalled… and based on that I’d argue that the state-of-the-art for exploit development is ahead of the curve for now.”
“Intel CET [Control-flow Enforcement Technology] will presumably help (assuming that you have an out-of-process JIT process), but it could be many years until broad adoption. For data-based attacks, stronger sandboxing and site isolation appear to be the best investments,” Hawkes added.
Microsoft’s perspective on the security vulnerability battleground “tracks very close with Projects Zero’s experiences/observations over the past couple of years”, according to Hawkes.
He concluded: “It’s the acceptance that we can’t exclusively engineer our way out of the problem with mitigations and sandboxing alone that I find significant here.”
RELATED CVE board looks ahead to the next 20 years of vulnerability identification
