“Rewrite it in Rust” is something of an ageing meme at this point – shorthand among developers for glib oversimplification of complex software issues. Performance issues? Rewrite it in Rust. Insecure application? Rewrite it in Rust. Maintenance issues? Rewrite it in Rust.
A new report from the White House Office of the National Cyber Director (ONCD) published on February 27 suggested to some observers this week that a flag bearing this meme has been planted in White House grounds.
“C is now illegal” as one developer joked on X – as the report claimed that “using a memory safe programming language is the most efficient way to substantially improve software security.” (The report actually only mentions Rust once, referring to the widespread use of non-memory safe C and C++ in space systems and Rust’s lack of maturity in this domain.)
The report makes the case that tech frims can prevent entire classes of vulnerabilities from entering the digital ecosystem by adopting memory safe programming languages. National Cyber Director Harry Coker said: "We, as a nation, have the ability – and the responsibility – to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem but that means we need to tackle the hard problem of moving to memory safe programming languages."
It was welcomed by Mark Stockley, who works in threat intelligence at Malwarebytes, who told The Stack: “If memory safe languages were the norm rather than the exception… a huge proportion of the most serious security flaws simply wouldn't exist.” The ONCD report cites a 2019 Microsoft report to make this same claim. Yet that’s controversial.
Analysis of “known exploited” vulnerabilities added to CISA’s KEV catalogue in 2023 actually showed that memory corruption accounted for just 19.5%; albeit with a disproportionate impact – more on that below.
Stockley added: “There are already efforts underway to rewrite core parts of Microsoft Windows, Android, the Linux Kernel, and the Linux toolchain in the memory safe language Rust, but much more needs to be done.”
“With CISA's [recent] The Case for Memory Safe Roadmaps and explaining The Urgent Need for Memory Safety in Software Products, the federal government seems to be trying to move the Overton Window on memory safety by making it a clear strategic priority,” he added.
Not all Rust: White House report has its eye on vendors
The report hints at more pressure from public policy makers and the federal government on software suppliers that have long been immune to any consequence for shipping insecurely built software – but in The Stack’s view adds little of real substance, unlike a report the same week on improving cyber-physical resilience across critical infrastructure.
See also: CISA's going to name and shame vendors on insecure software
“For far too long, primary responsibility for the cybersecurity of an organization has rested with the CISO of the company using software.”
“They cannot be the only stakeholder accountable for cybersecurity outcomes; it is also critical, for example, that the CIO who is buying software, and the CTO of manufacturers building software share this responsibility,” the ONCD paper said. “With better metrics, CTOs could use a range of rigorous analysis methods… to assure that vulnerabilities in a piece of software will be rare,” it added, somewhat nebulously.
So what’s the point here?
Policy makers in certain quarters have long advocated regulating for better quality software production and even product labelling.
They haven’t achieved it, even if some vendors do seem to be slowly recognising that pushing out software like Swiss cheese is getting increasingly unpopular with federal agencies; not least when they get hacked as a result, as has been the case with Microsoft in recent months.
See also: Microsoft pledges a dramatic software security overhaul, as Amazon veteran shakes the tree
The advisory harks back in some areas to some pillars in 2019’s cross-party US “Solarium Commission”, which highlighted a need to “incentivize product manufacturers to scrap a ‘first to market’ mentality.”
That report had warned industry bluntly that the “aggregated vulnerability assumed by [vendors] has created a significant national concern: rampant insecurity that passes costs of billions of dollars to downstream consumers and that has the potential both to disrupt our day-to- day life and to undermine public confidence in and the effectiveness of key institutions…” But hard action to drive change is elusive. And is the report even accurate on the centrality of memory corruption issues et al, when it comes to exploitation of vulnerabilities?
Arguably not. A recent report by offensive security specialists at Horizon3.ai noted that “nearly half of vulnerabilities are enabled by insecure exposed functions. At a strategic level we’ve seen recent pushes for security improvements by pursuing memory safe languages and software bill of materials (SBOM), but a seemingly asymmetric amount of effort or strategy around addressing this vulnerability category…”
The company said of the ‘insecure exposed functions’ that dominated (nearly 50%) as a cause of exploited bugs in 2023 that, vulnerabilities fall into this category when: “exposed dangerous code allows authorization bypass or remote code execution via insecure usage of command execution libraries, unrestricted deserialization, or file operations.”
Boris Cipot, Senior Security Engineer, Synopsys Software Integrity Group told The Stack: “As the document states – a shift to memory safe programming languages ‘offers a way to eliminate, not just mitigate, entire bug classes’ and therefore make software and hardware safer to be used. But one must be careful with how to understand this…
“Making sure the software is safe from memory corruption vulnerabilities does not make sure that there aren’t other attack vectors in the cybersecurity space that need to be taken care off. For example, in Python, packages from the PyPI package manager have been again found to be malicious. Another example is with the Rust package manager Cargo where the issue put UnNIX systems in potential risk. This means that even if one makes sure their application code is secure, sideloaded packages can, for example, still pose a security issue. Therefore, application security efforts cannot be disregarded or lowered due to a usage of a programming language that is making one part of the software cyberspace safe… Long story short – memory safe programming is offering a way to make software and hardware more robust and safer… but diligence in the AppSec space is further needed to avoid catastrophes.”
Interestingly, meanwhile, despite memory corruption vulnerabilities (for which languages like Rust are immune) representing just under 20% of known exploited vulnerabliities in 2023, as Horizon3.ai’s researchers found: “Interestingly, 75% of the analyzed memory safety vulnerabilities have been exploited as 0-days by threat actors… When vulnerabilities are exploited as 0-days they typically have a much more widespread effect on the world given that patches often lag by weeks once they are discovered.”
Maybe Rust is the answer, after all.
