Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again
Redmond engineer hints at taking super-lang for a spin
Microsoft Security Response Center (MSRC) is waxing lyrical about the risks inherent in C and C++ coding, arguing it may be time to dump "unsafe legacy languages" and shift to more modern, safer ones.
The Redmond-based biz has long been a C++ shop when it comes to the programming that matters most to the company – the Windows operating system and the core Office applications, for example.
Gavin Thomas, principal security engineering manager at MSRC, however observed:
The majority of vulnerabilities fixed and with a CVE assigned are caused by developers inadvertently inserting memory corruption bugs into their C and C++ code. As Microsoft increases its code base and uses more Open Source Software in its code, this problem isn't getting better, it's getting worse.
He added "perhaps it is time to scrap unsafe legacy languages and move on to a modern safer system programming language."
When Microsoft tried to rewrite the Windows shell, making extensive use of C# and Windows Presentation Foundation, for the first attempt at Vista (codename Longhorn), the result was impossibly slow and the company made a famous "reset" back towards native code in 2004. Whether or not this was really the fault of .NET, memories are long and the experience was probably a factor in the Windows team creating a new user interface layer for the tablet side of Windows 8 using C++, rather than adapting Silverlight, which was then used in Windows Phone.
"If only the developers could have all the memory security guarantees of languages like .NET C# combined with all the efficiencies of C++. Maybe we can," wrote Thomas.
The language he has in mind is Mozilla's Rust, designed for system programming with an emphasis on speed, memory and thread safety, and other security features.
In Rust we trust: Brave smashes speed limit after rewriting ad-block engine in super-langREAD MORE
Thomas also promised Microsoft would explore "safer system programming languages", starting with Rust, in another new blog series. That, in itself, is not of great note. It is the implications of this post that are of more interest. Thomas wrote:
You're probably used to thinking about the Microsoft Security Response Center as a group that responds to incidents and vulnerabilities. We are a response organisation, but we also have a proactive role.
If that role goes beyond lecturing the outside world about the benefits of not using C or C++, and into the realm of persuading internal developer teams to move away from "unsafe legacy languages", that has significant implications for the company's culture.
There are, of course, ways to code safely in C++, using Smart Pointers, provided by the Standard Template Library (STL), or a garbage collection library, for example. In the past, Microsoft has focused on promoting secure coding practices and providing tools to detect issues. Thomas's point, though, is that preventing memory bugs is a burden on developers that can now be bypassed.
That said, neither Microsoft nor the open-source projects to which Thomas refers can easily change course. Existing code, developer skills and the huge ecosystem of tools and libraries around C and C++ means that shifting to safer languages is a slow and long-term process, even if there were a consensus that this is the right thing to do.
Nevertheless, this is a remarkable statement from a small but influential corner of Microsoft and one that will be widely debated, as well as drawing more attention to Mozilla's Rust project. ®