How to make C++ memory-safe? Chrome targets UAF bugs with garbage collection

The solution to use-after-free (UAF) bugs is … to not free memory. Or, at least, to delay freeing it until after a quarantine period.

Google’s Chrome team is the latest group to jump on the “temporal memory safety” bandwagon. Much as they’d love to rewrite Chrome in Go or Rust, that’s a whole heap of work.

The performance impact of garbage collection seems to be pretty small. In today’s Secure Software Blogwatch, we give three cheers for pragmatism.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: 50 mph with a pulse jet between your legs. 

[ Get key takeaways from a survey of 300+ security professionals on software security. Plus: Download the report: Flying Blind: Firms Struggle to Detect Software Supply Chain Attacks ]

Peace sign of the times

What’s the craic? Liam Tung reports—“How Google is improving C++ memory safety”:

“Stop the reuse of memory that is still reachable”
Google and Microsoft are major users of and contributors to the fast programming language C++, which is used in projects like Chromium [and] Windows. … There is growing interest in using Rust because of its memory safety guarantees. But switching wholesale from C++ in Chrome to a language like Rust simply can't happen in the near term.
…
[So] Chrome engineers have found ways to make C++ safer to reduce memory-related security flaws such as buffer overflow and use-after free (UAF), which account for 70% of all software security flaws. [The] team have been exploring the use of a "memory quarantine" and heap scanning to stop the reuse of memory that is still reachable.
…
Google already uses C++ smart pointers like MiraclePtr, which also caused a performance hit, as well as static analysis, … C++ sanitizers, code fuzzers, and a garbage collector called Oilpan. … Heap scanning [and quarantine] may add to this arsenal if it makes it beyond experimental phase.

 
Interesting. What does Google have to say? Anton Bikineev, Michael Lippautz and Hannes Payer measure twice—“Retrofitting Temporal Memory Safety on C++”:

“Regresses the total score by 8%”
The majority of high-severity [Chrome] security bugs are UAF issues. … The basic idea [of] memory quarantine … is to put explicitly freed memory into quarantine and only make it available when a certain safety condition is reached. [We want] to avoid reusing memory until it has been proven that there are no more (dangling) pointers referring to it [by overriding] the memory allocator providing new and delete.
…
At some point a heap scan is triggered which scans [for] references to quarantined memory blocks. Blocks that have no incoming references … are transferred back to the allocator where they can be reused. … Running our basic version on Speedometer2 regresses the total score by 8%. … Unsurprisingly, heap scanning is memory bound and quite expensive [but] optimizations helped to reduce the … 8% down to 2%.
…
Hardware memory tagging may [allow] high performance. … MTE (Memory Tagging Extension) is a new extension on the ARM v8.5A architecture [but] since the number of tag bits is finite there is a chance that the tag of the memory and the pointer match due to overflow. [So] upon overflowing the tag, the object is then put into quarantine. … This reduces the number of scans and their accompanying cost by ~16x.

 
Clever approach or ugly hack? You decide. fulafel likes it:

Cool stuff. Reminds me a bit of Boehm-Demers' GC that can be used with C/C++. [It] made free() a no-op and used heap scanning to find garbage, though that wasn't security motivated.

 
And so does AmiMoJo:

It's also a significant step forward in terms of performance compared to previous custom allocators. It's a topic that has been studied a lot over the decades and it's not a trivial one to solve, so their results are actually pretty interesting. Not least because they have it working in a real-world, highly complex application, which can be realistically benchmarked.

 
And is 2% a lot of perf loss, anyway? u/sanxiyn thinks not:

Overhead is lower than I thought. … Google seems to disagree, but performance … without hardware acceleration [of] temporal memory safety seems acceptable to me.

 
But some say it still smacks of ugly hackage. masonwheeler sounds slightly sarcastic:

Looks like their "solution," rather than abandoning a terrible language they should never have picked up in the first place, is to make Chrome use even more memory. Lovely.

 
Ugly is as ugly does. SuperKendall agrees:

Pretty sure if you look in the dictionary under the definition of "Hack" it just links to this. [I] despair that even today, with … browsers used so heavily in all aspects of life, even the most fundamental browser security is still really a big joke.

 
So, why not simply reference-count and copy on modify? eklitzke explains why that’s even slower:

Of course you should use reference counting for things that actually need to be reference counted, and there's a standard mechanism in C++ for doing this (std::shared_ptr). However it's really only appropriate to use … for things that actually have indeterminate lifetimes, because it requires heap allocation and … use of atomics.
 
Most references/pointers in most C++ programs have simple scoping/lifetime requirements and don't require this overhead. If something retains a pointer to an object that is destroyed or goes out of scope, that can just as easily indicate that there is a logic error in the code retaining the dangling reference and therefore using std::shared_ptr or some other reference counting scheme isn't necessarily going to fix things.

 
Meanwhile, perhaps we should periodically throw code away and start again? This time, in Rust or Go. u/feverzsj dreams a dream:

Maybe modernize your codebase a little bit, Google?

 
And Finally:

Don’t try this at home, kids

Previously in And Finally

You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.

Keep learning

• Download the free report: Flying Blind: Firms Struggle to Detect Software Supply Chain Attacks.
• See interactive sample reports to help your team stop software supply chain attacks and improve your security approach.
• Find out about how to secure your CI/CD workflows. 

Image sauce: Lucian Alexe (via Unsplash; leveled and cropped)