At BlueHat IL 2019, Microsoft engineer Matt Miller described how the software vulnerability landscape has evolved over the last 20+ years, and the approach Microsoft has been taking to mitigate threats. Interestingly, among the major culprits of security bugs, says Miller, are memory safety issues, which account for 70% of total security bugs Microsoft has patched.
The analysis of the root causes of security vulnerabilities is the first step that can be taken to define a correct approach to risk mitigation, according to Miller.
What's noteworthy here is that at a macro scale, going all the way back to 2006, memory safety issues remain the most common kind in this category of vulnerabilities that we're looking at. About 70% of the vulnerabilities that are addressed through a security update each year are related to a memory safety issue.
Memory safety is a big category, including several kinds of issues, from stack and heap corruption to use after deallocation, uninitialized memory access, and so on. Analyzing the evolution of those sub-categories, Miller points out that stack corruptions went from contributing a non-trivial proportion of vulnerabilities to being almost non existent. Similarly, usage after deallocation accounted for more than 50% of vulnerabilities in 2013-2015 due to Web browser bugs and then decreased significantly thanks to the use of garbage collection. On the other hand, heap out-of-bounds read, type confusion, and uninitialized access have increased across the last few years.
Moving from discovered vulnerabilities to actually exploited vulnerabilities, Miller shows a slightly different picture, where accessing memory after freeing it and heap corruption are the most exploited kind of vulnerabilities.
The reason why this is interesting is because this provides us hints in terms of what are the types of vulnerabilities that may be easier or more preferred by attackers in terms of going and trying to exploit them.
Knowing where security issues arise and what kind of vulnerabilities attackers prefer does not actively contribute to reducing vulnerabilities of a software system, though. For this, a number of challenges must be overcome, says Miller.
We still do see many of the making some of the same mistakes that were made 10 years ago.
This has to do with a number of reasons, including the complexities of dealing with undefined behaviour in languages like C and C++, lack of tools or training, or even the fact that software is increasingly developed at different groups following different security policies and standards.
Another area where progress can be made is finding ways to break exploitation techniques. Indeed, exploits tend to use the same general pattern where you leverage a vulnerability to read or write from an arbitrary memory location and get the chance to discover interesting things about the program, such as which DLLs it uses and so on. Using that information, you set up a malicious payload that you use to try to hijack the control flow of the program, such as by corrupting a function pointer, or a virtual table pointer, and so on.
Summing it all up, says Miller, the most promising approach to reducing vulnerabilities is aiming for a more radical shift where you:
- Make unsafe code safer by eliminating common classes of memory safety vulnerabilities.
- Use safer languages, such as C# or Rust, or improve existing languages like C++.
- Improve development process and tools, including compiler autofix and alike.
There is a lot more in Miller's talk that can be covered here. Do not miss his talk video recording to get the full detail.
