What if we were able to completely eliminate a class of vulnerabilities?
The Microsoft Security Response Center ( MSRC ) has evaluated each Microsoft security vulnerability that has been reported since 2004. One startling fact stands out from all of that triage: according to Matt Miller’s 2019 BlueHat IL presentation, developers unintentionally add memory corruption bugs to their C and C++ code to fix the majority of vulnerabilities and assign them a CVE. This issue is n’t getting better; it’s getting worse as Microsoft expands its code base and incorporates more Open Source software. Additionally, Microsoft is not the only company that is affected by memory corruption bugs; MSRC only receives them.
Figure 1: Memory safety concerns continue to account for 70 % of the CVEs Microsoft assigns each year.
Not that there are n’t tools available to assist programmers in writing secure code. The developer has access to a wide range of tools, including constraint solvers, fuzzing at scale tools ( which offer haystacks of crashes to triage ), and incredibly complex static analysis tools. The Secure Development Lifecycle, encyclopedias of coding standards, hours of code review, plenty of training, and threat modeling guidance are all available to assist developers in implementing secure practices. To save developers from mistakes, we changed the compilers and developed mitigations. Even the squiggly red lines in Visual Studio point out potential flaws!
That is not all, though. We are there for the developer, prepared to point it out and assist them with their post-mortem when an internal or external reporter finds a security flaw. After pleading with them to fix the problem in their feature writing, we push Update Tuesday’s release. What more could security engineering provide the developer?
To build features without security flaws, they might want to put less effort into learning tools and procedures.
A case for languages that are memory-safe
The main responsibility of a developer is to work on features, not security. What about a development language where memory safety concerns ca n’t even be brought up in the first place, rather than spending money on ever-more tools, training, and vulnerability fixes? That would benefit the customers as well as the security engineers and feature developers.
The responsibility for software security is transferred from the feature developer to the language developer when a language is deemed safe from memory corruption vulnerabilities. Fortunately, a number of languages, including C#, are thought to be” safe” from memory corruption vulnerabilities. Many Microsoft development teams have embraced the idea of creating new customer-related features using these secure languages.
C++ does have some advantages that make it appealing and, in some cases, necessary: it is blisteringly quick, has a small memory and disk footprint, is mature, executes smoothly, and has an almost unmatched platform. If only programmers had access to all the advantages of C++ and languages like .NET C# in terms of memory security. Perhaps we can: Mozilla’s original Rustprogramming language is one of the most promising modern systems programming languages that meets these requirements.
Focusing on the developer’s tools rather than being overly distracted by security jargon, hype, non-data driven ideologies, and out-of-date methods and approaches is important if the industry is truly concerned with security. We should work to stop the developer from introducing flaws in the first place rather than offering instructions and tools for fixing them.
One squirrel at a time, increasing security
A squirrel crossed the road in front of me as I was heading to work today. I swerved to avoid it after making a quick brake. However, neither the squirrel nor I were injured when I struck it. The anti-lock braking system prevented me from skidding into the other lane, and my seatbelt protected me in my position, not because I had to take some complicated actions. The safety features in my car that prevented me from hitting it and causing another accident helped the squirrel and I both fare better.
The automotive industry’s ongoing technological advancements to safeguard drivers and road users can teach us something. Similar protection for the developer is a right of the software security sector. Maybe it’s time to switch to a safer, more modern system programming language instead of using outdated, dangerous legacy languages.
You’re probably accustomed to picturing the Microsoft Security Response Center as a crisis- and vulnerability-relieving organization. In a new blog series, we will highlight Microsoft’s investigation of safer system programming languages, beginning with Rust, despite the fact that we are an organization that provides responses. Please come along for the ride.
Gavin Thomas, MSRC’s principal security engineering manager