Alex Rebert

Hardening the C++ Standard Library at massive scale. A look at increasing memory safety with libc++ hardening — a collaborative paper from engineers at Apple and Google. The results have been impressive: at Google the team discovered and fixed 1000+ bugs as hardening was enabled. queue.acm.org/detail.cfm?id=…

We're joining forces with industry & academia to call for memory safety standardization: security.googleblog.com/2025/02/securi…. It's a recognition that memory unsafety is no longer a niche technical problem but a societal one, impacting everything from national security to personal privacy.

🛡️Want to help make the open source world safer and earn up to $45k 💰? We've revamped our Patch Rewards Program, extending its scope and increasing rewards for security patches – with a particular focus on memory safety, including bonus multipliers! bughunters.google.com/blog/527306491…

Celebrating 15 years of password hacking 💻 🔑, Swiss Army knives (and sometimes even chainsaws or swords) included! 😲 Discover how Google's security teams turn employee farewells into security tests. bughunters.google.com/blog/635526578…

@kupiakos Oops, I missed this. OOB accesses terminate the program immediately. See #hardening-assertion-failure" target="_blank" rel="nofollow noopener">libcxx.llvm.org/Hardening.html…

@ayper Does OOB access yield an abort or an unwinding exception?

Excited to share our latest post on memory safety! We're tackling spatial safety in our massive C++ codebase by hardening libc++ *by default*. It adds bounds checks to things like std::vector, preventing a fair bit of out-of-bounds vulnerabilities: security.googleblog.com/2024/11/retrof…

Bounds-checking in C++: so people ask if the .3% overhead is real. It's not just a benchmark result, we got this through our Google-Wide profiling, that gives us the live insights from DCs. This surprised us too as it was much cheaper than we thought research.google/pubs/google-wi…

@RoseSilicon The blog post is mostly about server-side code, where it was recently rolled out. But chrome also has it on since 2022.

@seanbax In particular, you can see the enabled checks with: - github.com/search?q=repo%… - github.com/search?q=repo%…

@seanbax That's right! Hardening does a few more things than just bounds checking: empty optional checks, sanity checks on sizes, sort ... I'm not aware of a comprehensive list -- I usually grep for the 2 enabled libc++ macros defined in #L43" target="_blank" rel="nofollow noopener">github.com/llvm/llvm-proj…

The best part? It's incredibly cost-effective, with an average performance overhead of just 0.30%.  So there's really no reason not to do it if you're running C++ code :)

This improves spatial memory safety across Google's services, including performance-critical components of Search, Gmail, Drive, YouTube, and Maps.  We've already seen it disrupt a red team exercise, reduce segfaults by 30%, and improve code correctness.

The dedication and hard work has payed off: "for hundreds of complex web applications that are built on Google’s hardened and safe-by-design frameworks, we've averaged less than one XSS report per year in total" (see page 9 of the whitepaper).

Percentage of codebase that's memory-safe 📈, memory-safety vulns 📉, EVEN IF YOU KEEP ADDING LINES OF C 🤯

Excited to share Google's memory safety strategy! We're working to build safer software by migrating to memory-safe languages like Rust as well as hardening our existing C++: security.googleblog.com/2024/10/safer-…. We'll be sharing more details in upcoming posts.

Google CVR is doing incredible vulnerability research.

@lauriewired Our team at Google just published a blog post with related findings on the half-life of vulnerabilities and how prioritizing safety in new code can dramatically improve overall security: security.googleblog.com/2024/09/elimin…

Regular, sustained changes in non-concentrated periods do not have the same correlation with defects. What do you think? It seems like a fascinating early-warning canary of future code issues. I'd love to see a trained model warn a team of future maintenance load based on current code commits. Cassandra seems like an appropriate name.

The half-life of code is an interesting predictor of project quality. Linux, has one of the longest code half-life’s at 6.6 years. WordPress, less than 2. Every software change induces some risk. Repos with numerous "change bursts" have the highest incidence of defects.

@sephr The simulated results, which closely match the empirical data in Android, did not assume any prioritization. So prioritization does not appear to explain the effectiveness of this strategy, although it may explain why the Android results outperformed the simulation.

@ayper Isn't it obvious that if you have a choice to use memory-safe languages, it will be used where it matters most? I don't find these results counterintuitive.

The drop in Android's memory safety vulnerabilities is astonishing. It's counterintuitive, but prioritizing memory-safe languages in new code quickly reduces memory-safety risks. Once we turn off the tap of new vulnerabilities, they start decreasing exponentially.

@sephr Because the risk reduction far outweighs what one would expect from the % of memory-safe code. Android has *more* memory-unsafe code than it did in 2019, and yet, it has almost an order of magnitude fewer memory safety vulns.

@ayper How is it counterintuitive that prioritizing memory-safe languages in new code reduces memory-safety risks?

@seanbax Thanks :) And yep, ~1.7y would be the half life in the simulation based on the 2.5y average lifetime.

@ayper Cool result. It seems both crazy and perfectly logical. What's the half-life used in the simulation? The foot note says the average lifetime is 2.5 years, does that mean the half-life is only 2.5y * ln(2) = 1.7y?