Alex Rebert

Security @ Google. Previously co-founder of @ForAllSecure. Opinions here are my own. @[email protected]

[[email protected] @Zardus]

Can we translate all C to Rust? The susceptibility of C to memory corruption has long been a cybersecurity pain point, and coding agents can free us of it. Read on for my recent experiments in this space, and apt & docker repos that you can pull rust-converted libraries from!

[Heather Adkins - Ꜻ - Spes consilium non est @argvee]

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. https://t.co/7kxWdfq2dD

[Alex Rebert @ayper]

We're joining forces with industry & academia to call for memory safety standardization: https://t.co/UOVODzi0RZ. 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.

[Google VRP (Google Bug Hunters) @GoogleVRP]

🛡️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!

https://t.co/pUiYgTRdsA

[Google VRP (Google Bug Hunters) @GoogleVRP]

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.

https://t.co/Mapn7Nrs78

[Alex Rebert @ayper]

@kupiakos Oops, I missed this. OOB accesses terminate the program immediately. See https://t.co/Q3ZeqTjhwj

[Alex Rebert @ayper]

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: https://t.co/Dek3jJaTxn

[Kinuko Yasuda @kinu]

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
https://t.co/zBUvoYzGi1

[Alex Rebert @ayper]

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

[Alex Rebert @ayper]

@seanbax In particular, you can see the enabled checks with:
- https://t.co/J92hwXKmYb
- https://t.co/d6weQzlCO4

[Alex Rebert @ayper]

@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 https://t.co/zuxcMG2Psy

[Alex Rebert @ayper]

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 :)

[Alex Rebert @ayper]

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.

[Lukas Weichselbaum @we1x]

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).

[Deirdre Connolly¹ @durumcrustulum]

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

[Alex Rebert @ayper]

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++: https://t.co/UdmcghPhbO.

We'll be sharing more details in upcoming posts.

[Alex Rebert @ayper]

Google CVR is doing incredible vulnerability research.

[Anthony Weems @amlweems]

Learn how Google CVR could have potentially exfiltrated Gemini 1.0 Pro before launch last year. We describe the vulnz, the fix, and tips for bughunters. Also, shout-out to @epereiralopez for teaming up to adapt this work to another cloud provider.

https://t.co/65PY5o3mtV

[Alex Rebert @ayper]

@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: https://t.co/psyHZAsD0A

[Alex Rebert @ayper]

@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.

[Alex Rebert @ayper]

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.

[Jeff Vander Stoep @jeffvanderstoep]

I’m super excited about this blogpost. The approach is so counterintuitive, and yet the results are so much better than anything else that we’ve tried for memory safety. We finally understand why.
https://t.co/cBc3gMLzO6

[Alex Rebert @ayper]

@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.