Mastodawn

jeffvanderstoep Oct 17, 2024

I joined @durumcrustulum and @tqbf 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.

A Little Bit of Rust Goes a Long Way with Android

You may not be rewriting the world in Rust, but if you follow the findings of the Android team and our guest Jeff Vander Stoep, you’ll drive down your memory...

Show thread

jeffvanderstoep

@durumcrustulum @tqbf

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)

Show thread

Lee Holmes

Oct 17, 2024

@jeffvanderstoep @durumcrustulum @tqbf

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

Great point, and our industry misses opportunities for this all the time. When we were looking to make PowerShell less attractive to attackers, attempting only to remove its power would have been a fool's errand.

By focusing on making it the noisiest possible tool to use, we made far more progress: https://devblogs.microsoft.com/powershell/powershell-the-blue-team/

PowerShell ♥ the Blue Team - PowerShell Team

(Warning: Long blog post ahead! If you’d like to read (or share) this as a whitepaper, you can download it here: “Scripting Security and Protection Advances in Windows 10”). At Microsoft, we invest an enormous amount of time and energy managing world-class cloud services and incredibly large enterprise networks. Security is critical for all of […]

PowerShell Team