3 ms·
So called "post-exploit" mitigations are practically always only hardening, i.e. making subsequent attacks harder (and fewer). Ideally much harder. But if you w
by anyfoo 2y ago
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.
- snvzz 2y agoCapabilities (as implemented in e.g. seL4) is the way to go.
- gizmo686 2y agoCapabilities 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.