A computer security blog with an analytical bent.
When trying to exploit a memory corruption bug on a reasonably hardened target, there’s a tradeoff around where to invest time. Would it be most efficient to try and find the most powerful, most readily exploitable bug possible? Or would it be better to stick with the first decent bug you find and invest time instead in developing a really great exploit technique that will make up for the bug’s…
One way of seeing the difference between memory-safe and memory-unsafe languages is that in a memory-safe language, the invariants used to uphold memory safety only “lean on” invariants that are enforced entirely by the language, compiler, and runtime, while in a memory-unsafe language the invariants used to uphold memory safety can “lean on” programmer-created (and thus programmer-breakable)…
One thing I’ve often been frustrated by while working on a security team at a large company is a seeming lack of understanding of the difference between code auditing and vulnerability research. These two activities appear superficially similar: they both involve looking at code to find vulnerabilities and improve security. But they have fundamentally different goals, different framings during the…
In this post I want to share a few thoughts on some more theoretical aspects of memory safety. These points aren’t necessarily new, but I feel like they’re sometimes underappreciated.
Why do most in-the-wild exploits that target end-user platforms use memory corruption?