Memory corruption bugs in C and C++ code are the main source of software security vulnerabilities today. Microsoft is looking to address that by encouraging developers to adopt Firefox maker Mozilla’s "safe" Rust programming language.
The Microsoft Security Response Centre (MSRC), which is responsible for handling all security bug reports to the Redmond firm, has outlined its case for developers using “memory-safe languages” and highlights Rust as one answer to help developers focus on feature development rather than wrestling bugs they introduce while coding in C and C++.
Rust, a relatively young language, was hatched a decade ago at Mozilla and was a key piece in the revamped Quantum-based Firefox browser released last year. Rust is currently the 33rd most popular language, according to the Tiobe language index and is used in a diverse range of projects from Dropbox, Oracle, RedHat, Cloudflare and Microsoft. The much older C and C++ meanwhile are both top 5 languages.
The possible move on Rust adds to Microsoft’s big bear-hug of open source software as part of its focus on cloud rather than the Windows operating system, including its recent switch to Chromium open source code for the Microsoft Edge browser, its acquisition of open source code hosting site GitHub, and open-sourcing .NET. Once upon a time Microsoft's leadership called open source Linux a cancer.
Gavin Thomas, a principal Security engineering manager at MSRC, reckons Rust is “one of the most promising newer systems programming languages” that offers developers both the speed of C++ and the safety of Microsoft’s own .NET C# (C sharp) language.
“Rather than providing guidance and tools for addressing flaws, we should strive to prevent the developer from introducing the flaws in the first place,” argues Thomas.
The security engineer draws a comparison between software development security and safety features that are built in to modern vehicles.
Safety features like seatbelts, ABS braking, and airbags in vehicles are a common reference point in discussions about the economics of automobile safety, which was ignored by the US auto industry in the ‘50s and '60s due to the belief that customers would not be willing to pay more for additional safety.
“As I was driving to work today, a squirrel ran across the road in front of me. I braked quickly and had to swerve to avoid it," Thomas wrote.
" But I didn’t hit the squirrel, and I didn’t get hurt myself. Not because I took some complicated actions, but because the anti-lock braking system kept me from skidding into the other lane, and because my seatbelt kept me protected in my seat. The squirrel and I were both better off because of the safety features built into my car that helped me avoid both hitting it and causing another accident.”
A corollary for software developers to safety features in vehicles are practices in Microsoft’s Secure Development Lifecycle, its Visual Studio “squiggly red lines to highlight potential flaws”, and the company’s work helping developers fix their own software bugs as part of its Patch Tuesday updates.
Microsoft doesn’t outline exactly how it plans to proceed with its Rust excursion but Thomas suggests Rust could be an answer to developers spending “less effort on learning tools and processes to build features without security flaws.”
“The software security industry has a prerogative to protect the developer in a similar manner. Perhaps it’s time to scrap unsafe legacy languages and move on to a modern safer system programming language?”
Thomas said Microsoft will be outlining its plans in a series of blogposts about safer programming languages that starts with Rust but also canvasses other memory safe languages.
“We are a response organization, but we also have a proactive role, and in a new blog series we will highlight Microsoft’s exploration of safer system programming languages, starting with Rust. Please do join us on our journey.”
The emphasis on memory-safe languages could help address what MSRC researcher Matt Miller highlighted in a talk at BlackHat 2019: that the majority of bugs assigned with a CVE number are due to developers accidentally adding memory corruption flaws into C and C++ code.