Hacker News new | ask | show | jobs
by cahoot_bird 547 days ago
Super interesting. At one point thought control flow guard + DEP/ASLR was suppose to prevent this stuff, guess it can't be prevented nearly completely by now. Sounds like this took a lot of work to figure out, well done.

Any comment on reporting to Microsoft or perhaps motivation for this research?

1 comments

So called "post-exploit" mitigations are practically always only hardening, i.e. making subsequent attacks harder (and fewer). Ideally much harder. But if you want an absolutely, provably (within limits, i.e. halting problem etc.) secure system, you have to eliminate bugs that can lead to any exploitable situations beforehand. In this case for example, that would mean no situation existing that could cause a buffer overflow in the first place. Memory-safe languages help for this case.

Obviously this is hard, so post-exploit mitigations will likely continue to still make things harder for attackers for quite a while at least.

Capabilities (as implemented in e.g. seL4) is the way to go.
Capabilities are a better security model, but don't protect you from kernel bugs. Provably correct kernels (such as seL4) do.

Having said that, being a microkernel, seL4 ends up pushing a bunch of potentially buggy code to use space. There are real benefits to that, but if you can exploit the page table server, the system is pretty much yours.