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."

Microsoft has other programming languages that are safer to use, thanks to automatic memory management. C# and the .NET family is one, and TypeScript, which compiles to JavaScript, is another. These languages are used extensively both by Microsoft and its customers, but they are not suitable for every purpose.

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.

Someone riding a make believe rocket

In Rust we trust: Brave smashes speed limit after rewriting ad-block engine in super-lang


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. ®

Similar topics

Other stories you might like

Biting the hand that feeds IT © 1998–2021