Memory Corruption Hardening is Controversial Now?
Social Media has a lot of criticism lately for the push for memory safety as a metric for the labeling of software security. Between software supply chain susceptibility, command injection, and logic bugs obliterating software regularly, it doesn't seem like its the best candidate for a software safety metric.
The background for why the federal government is reporting in the area is E.O. 14028
From the EO there's several pushes for software and network safety. These are things like requiring Zero Trust Access for the Federal Government, EDR on federal systems for monitoring and responding to attacks, SBOMs for supply chain safety, and creating safety standards for IOT devices. Although the main focus is the federal government there's an aim to push out software safety standards to the public as a whole.
And it's regulation for consumers that I see getting some criticism. NIST's key areas interact with the labeling of safety for IOT and consumer software -- which has everyone skeptical because the government may not seem to be the best equipped for leading edge software practices, and regulatory overhead will raise the burden for software developers without necessarily moving software security forward.
On memory safety specifically, two key documents have been released over the past two quarters. The first is CISA's report on Memory Safety. The second is the ONCD Report on Measuring Memory Safety.
Software Looks Very Fragile When You're Good At Exploitation
My take on memory safety is that it looks a lot more urgent from the vantage point of an organization with a fully stocked arsenal. Many pieces of software really start to look like an open door. And there's just a lot they see the public doesn't have regular access to.
To an individual or even a team of defenders at a top 10 tier tech company, things might seem a lot less urgent than they do the whitehouse because exploitation has become difficult. We've come quite a long way since Operation Aurora where attackers could spray the 32-bit address space with nops and shellcode to execute code. Between 64-bit address spaces, CFI, ASLR, memory tagging, MTE, shadow stacks, EDR kernel sensors, single-process unikernels, scanners in security coprocessors, yes -- whole swathes of crashes are made interceptable, unexploitable, or vastly unreliable.
It takes whole teams to make successful exploit chains against rich and common attack surfaces. However, if the cost of not having a capability is more than the price of making it, it becomes increasing probable that an exploit will exist until software begins to be fundamentally secure. Ten million, fifty million, a hundred million dollars seems like a ton of money for an exploit chain that's one patch away from disappearing. But to the federal government that can create trillions of dollars to solve a global crisis, that amount of funding remains a rounding error.
Likewise, defenders at the US federal government and its partners have access to ongoing and recent attack trends. They see how attackers surreptitiously take advantage of flaws that may not always become public or fully known. To them the situation might look a lot more untenable than it does to leading edge software developers from the tech giants.
Defender Advantage Through Regulatory Controls
On one hand -- regulatory burden like we've seen with GDPR in the EU can really hurt developers, as well as user experience. Does anyone feel like the EU solved privacy for citizens or do they feel more surveilled than ever? On the other hand, regulation might just be the thing that helps secure software overcome the marketing department at Insecure Vendor Co. or helps Ada win against C or creates a market for new architectures.
On performance: if we're cool with shipping web browsers as native apps with a million NPM packages, we'll probably survive okay with compilers that waste instructions.