jeffvanderstoep

https://infosec.exchange/@jeffvanderstoep

Public Key

npub1aw8l0s85w9mhef4kv7hxzkc9dcfuhc8526egseldka5hr72clm3qqlz2wr

NIP-05 Address

Profile Code

nprofile1qqswhrlhcr68zamu56mx0tnptvzkuy7tur69dv5gvlkmw6t3l9v0acspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsuf867e

Publishing to

relay.ditto.pub

relay.damus.io

nos.lol

Author Public Key

npub1aw8l0s85w9mhef4kv7hxzkc9dcfuhc8526egseldka5hr72clm3qqlz2wr

Show more details

Last Notes

2024-10-17 15:10:28 GMT

- reply

One of my coworkers listened in and had some interesting takeaways:
1. The practicality of the Android team in tackling a problem: working incrementally right away without trying to solve for everything, and how that's almost always the right approach when you're doing big changes like this.
2. The shift away from being attacker focused: how that's applicable to more of security than just memory safety. I.e., don't focus on making the attacker's life harder by constraining yourself to their playing field, but rather focus on making the defender's life easier by focusing on the things that we control
3. It's more expensive to clean up a mess than to prevent the mess: It doesn't follow directly from the blogpost, but it's essentially the difference between "build something in a MSL" (developer-focused) or "build something in an unsafe language, and go and tack on a bunch of mitigations afterwards" (attacker-focused)

2024-10-17 15:05:30 GMT

I joined @npub1s92…gcnc and @npub1856…64fe on the Security Cryptography Whatever podcast to talk about our latest blogpost:
https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
Something that Thomas said in the podcast really stood out to me. He said “the blog post undersells it. …. This is a lot more interesting than it looks like on the tin.”
I agree with this. It feels like we discovered a game-changer not just in memory safety, but in security more generally - that doing something very practical results in major security improvements for non-obvious reasons. Focusing on new code is disproportionately effective, exponentially.
Thomas also said “And that observation about the half life of vulnerabilities, if that’s true, says something pretty profound about what the work looks like to shift to a memory safe future.”
Or as Deidre said: “You can get really big bang for your buck, which is if you have something new, just write it in the Rust or another memory safe language and make it interop with the rest of your project and you will in fact, get really good returns on mitigating your memory safe vulnerabilities, which is the majority of your vulnerabilities, period.”
Agreed. We’re already prioritizing differently based on this data. It was a fun conversation, and we believe that it applies to a lot more than just memory safety.

2024-09-27 18:57:50 GMT

- reply

Why? It's consistent across all projects that the cited "large scale" study analyzed. It's also consistent when we looked at Android, which was not part of the study. When we change the behavior of development within Android, the result matched what we would expect based on the half-life metric.
When you look at studies that analyze how this works from the opposite angle "how much does it cost to find the next vulnerability in the same codebase?" you'll see a similar result. E.g. "On the Exponential Cost of Vulnerability Discovery" https://mboehme.github.io/paper/FSE20.EmpiricalLaw.pdf
There's a finite number of vulnerabilities within a code base. As the density drops, the cost of finding the next vulnerability will rise.

2024-09-25 17:03:12 GMT

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://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html