White House Warns Against Using Memory-Unsafe Languages

The White House’s Office of the National Cyber Director urges developers to move to memory-safe languages such as Rust as soon as possible.

We’ve known for ages that we should use memory-safe languages like Rust. But, after lifetimes of deploying everything in C and C++, it’s not easy to do. Now, the U.S. White House’s Office of the National Cyber Director (ONCD) unveiled a comprehensive report, Back to the Building Blocks: A Path Toward Secure and Measurable Software. This isn’t an executive order or law, but it very strongly urges programmers to take decisive steps toward minimizing vulnerabilities by adopting memory-safe programming languages.

As ONCD Assistant National Cyber Director for Technology Security, Anjana Rajan, pointed out, many of the most catastrophic cyber incidents, dating all the way back to the Morris worm and the much more recent Heartbleed vulnerability, stemmed from memory safety vulnerabilities. Rajan emphasized the importance of addressing these issues at their root by making informed decisions in software and hardware development.

It’s not like we haven’t known this was a good idea for years now. Microsoft security engineer Matt Miller said in 2019 that over the last dozen years, 70% of all Microsoft patches were memory safety bug fixes. Though we like to make fun of Windows’ security — or lack thereof — this isn’t a Microsoft problem. It’s everyone’s,

Open source security company WhiteSource‘s study of open source security vulnerabilities in the seven most widely used languages over the past decade found C was the language with the most security bugs. Almost 50% of all reported vulnerabilities were in C.

True, WhiteSource several factors can explain the high number of open source vulnerabilities in C. For starters, C has been used longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructures like OpenSSL and the Linux kernel.

Nevertheless, as  Kees “Case” Cook, Google Linux kernel security engineer, observed: “C is a fancy assembler. It’s almost machine code.” In addition, “C comes with some worrisome baggage, undefined behaviors and other weaknesses that lead to security flaws and vulnerable infrastructure.”

Can You Write Secure Code in C and C++?

Yes, you can write secure C or C++, but it’s really, really hard, and that’s why so many mismanaged memory security holes pop up again and again.

So it is that Rust is now being used in the Linux kernel, and Mark Russinovich, Microsoft Azure’s CTO, said developers should avoid using C or C++ in favor of Rust. Microsoft isn’t just saying you should use Rust and the like. The Redmond giant is also rewriting Windows core libraries in Rust. The company also leaked that it was integrating Rust into Microsoft 365. Sure, Microsoft is insisting that it’s not abandoning C#, but you do have to wonder.

In this new, safer programming world, National Cyber Director Harry Coker highlighted the dual imperative of transitioning to memory-safe programming languages and developing advanced diagnostics to assess cybersecurity quality. “We have the ability — and the responsibility — to curtail the attack surface in cyberspace.”

While acknowledging that such a shift may not be feasible in every scenario, the report posits that, in most cases, it can be done. Furthermore, the ONCD calls on the industry to develop metrics to better assess software security, a move aimed at anticipating and mitigating systemic risks in cyberspace.

Notably, Jeff Moss, DEFCON and Black Hat‘s president, endorsed the report’s recommendations.

“Internet security problems are global problems, and solving them will require engagement from our Nation’s leaders. I commend the ONCD for taking the important first step beyond high-level policy, translating these ideas into calls to action the technical and business communities can understand. I endorse the recommendation to adopt memory-safe programming languages across the ecosystem because doing so can eliminate whole categories of vulnerabilities that we have been putting Band-Aids on for the past 30 years.”

The Open Source Security Foundation (OpenSSF) agrees. The OpenSSF stated, “By using memory-safe languages, software developers can significantly reduce the risk of vulnerabilities associated with memory safety when developing a brand new project or new components.”

But, the OpenSSF knows darn well this isn’t going to be easy. The leading open source security group declared, “Large-scale adoption of memory-safe languages is non-trivial. For example, rewriting all the existing C and C++ code is neither economically feasible nor practical. … Refactoring from one language to another often introduces new bugs, and the complexities of rewriting source code is just the beginning. After rewriting, deploying the latest software, especially in embedded systems such as those in our critical infrastructure, can be even more complicated, putting critical systems at risk.”

Therefore, the “OpenSSF recommends taking a risk-based approach towards refactoring the most critical components. OpenSSF has developed the Compiler Options Hardening Guide for C and C++ to help guide developers who can’t easily migrate to memory-safe languages.”

So, while we may be well on our way to adopting memory-safe languages, it’s not going to be a quick journey. For years, indeed, decades to come, we’re still going to rely on legacy C and C++ code. The best we can do is to make the best of our existing code and replace essential elements, such as the TLS library, with memory-safe Rust replacements.