A recent headline was published in several technology news outlets, at ZDNet “Microsoft: 70 percent of all security bugs are memory safety issues” and Fudzilla, “More than 70 percent of Microsoft patches are for memory problems.” Of course, if you build a tool that is specifically designed to detect these problems, these headlines raise eyebrows and pique interest. As it turns out, the original work the headlines are based on is done by Matt Miller at the Microsoft Security Response Center (MSRC.) This recent presentation done at the 2019 BlueHat conference in February, 2019, provides some interesting insight into security vulnerabilities.
12 Years of Memory Safety Issues
One of the startling revelations from Miller’s presentation is the continued trend of memory safety issues being the majority of security vulnerabilities. Microsoft’s data shows that for at least the last 12 years, memory safety issues have been the cause of 70% of the CVEs (common vulnerabilities and exposures) that had been patched. This definitely indicates there’s still room for improvement in development practices!
Source: Trends, Challenges, and Strategic Shifts in the Software Vulnerability Mitigation Landscape, Matt Miller, Microsoft Security Response Center, BlueHat IL, February 7, 2019
Root Causes of Memory Safety Issues
Even more interesting from our perspective is the same study’s investigation into the root causes of these memory issues. Most of the code analyzed is written in C and C++ and the Microsoft study found the same recurring root causes of memory errors: Heap out of bounds, use after free, type confusion and uninitialized use. If you’re familiar with static analysis tools, you know these are the types of errors that are detectable by static analysis.
Source: Trends, Challenges, and Strategic Shifts in the Software Vulnerability Mitigation Landscape, Matt Miller, Microsoft Security Response Center, BlueHat IL, February 7, 2019
The good news is these are detectable by static analysis and developers can find and fix these errors early in the lifecycle. The bad news is that the trends indicate things aren’t getting better despite better tools. There is more going on here and Miller’s presentation goes into more details as to what and why.
Challenges of Writing More Secure Code
The obvious question to ask when looking at the preceding data is “why haven’t things got better?” There are various challenges outlined in Miller’s presentation mirrors what we’ve been saying as well:
- The same classes of vulnerabilities continue to plague software development. It seems developers are making the same mistakes year after year. Although there are new classes of vulnerabilities such as Meltdown and Spectre, exploits favor the perennial error types.
- Developers are expected to prevent vulnerabilities with little or no training and insufficient tools. Training helps but the demands on modern developers often makes security “extra work” on top of a busy schedule.
- Software development is still being done with poor security policies and controls. Organizations try to tackle security too late in the development lifecycle or in an ad-hoc fashion. Low investment in security results in poor outcomes.
- Adopting third party and open source software means inheriting a variety security practices. Although reuse is essential for developer productivity, the security impact is often overlooked.
- Finding all vulnerabilities isn’t realistic. More vulnerabilities are found every year despite years of effort. A zero tolerance policy is impractical so a pragmatic approach is required.
Improving Software Security and the Role of Static Analysis
The offered solutions in Miller’s presentation are in line with what we have been promoting as well. Obviously, as a static analysis tools vendor we want to see our tools being used. However, studies like this show that adoption is not where it should be and there are still improvements to be made. The status quo has given us 12 years of memory errors. Consider Miller’s proposed actions towards achieving better security over time. I’ll consider these in terms of how tools like GrammaTech CodeSonar can help:
Make unsafe code safer: The best way to make code more secure is to reduce the number of vulnerabilities. Static analysis tools are well suited to detect the types of errors that are most commonly detected and exploited. Software teams can adopt static analysis at any stage of product and realize improved security. Detect memory errors before they even enter the code repository and build provides the best return on investment for the tools. However, static analysis is well suited for large code bases if necessary.
Transition to safer languages: Although it’s impractical to change languages midway through a project or to adopt a new language for a safety critical embedded system, it is possible to adopt a more secure subset of a language such as SEI CERT C.. Static analysis tools are ideal for helping teams evaluate their code against a known standard and for helping to enforce the rules on an ongoing basis. Even if C and C++ can be fraught with memory errors, more secure coding practices can help eliminate many of these issues.
Safer and more efficient development: Software teams need to adopt better security practices and give developers enough time and training to adopt these practices. One example would be using advanced static analysis tools such as CodeSonar which provides complete root cause analysis, execution traces and problem descriptions to help developer understand the exact issue. Over time, this improves developer knowledge of vulnerabilities and helps them prevent further incidence. Along with better security controls, coding standards and automated detection, it’s possible to reduce the overall vulnerability detection and remediation workload on the development team. Hopefully, automation can help buck the 12 year trend!
Summary
As expected there’s more to the headline that meets the eye. Microsoft’s study shows some interesting information about the root causes of security vulnerabilities and the popularity of each as an exploit. The challenges and observations made fall in line with GrammaTech’s experience in the marketplace as do the recommended approaches to help improve the situation. With better tools and techniques and more time invested in security, it should be possible to make headway into improving security.
Interested in learning more? Read our Guide “Enhancing Code Reviews with Static Analysis”
{{cta(‘c2c45658-dc38-4210-a8dd-c8033ad6e3e1’)}}
