Some of it also depends on the level you're interested in. EG I follow the International Association for Cryptologic Research (iacr.org) for information about cryptographic exploits & developments, but that's generally several steps away from practical use.
On the other hand, stuff like ASAN is great. I don't hear many people talking about it, sadly enough, outside Chrome team. Operating systems should enable that systemically. Sadly they never will. Because it actually finds real bugs, which take effort to fix. It's much lower effort to push non-breaking changes that make code slower and development less pleasant so you can claim victory at raising the iq bar for hypothetical bogeymen.
It raises the bar considerably when exploiting a remote system. Without ASLR, DEP is worthless, since reliable tools exists to produce ROP chains. I think I remember seeing a fully fledged compiler somewhere, that can take high level C code and 'compile' it into offsets on the stack given a target program.
Just ASLR for executable memory is not enough. In a local EOP situation it's very likely an attacker can find where specific modules are loaded in memory. On Windows this isn't even a secret, since modules are loaded in the same memory range for performance reasons.
Here you really also need heap layout randomization, the latest version of which shipped in windows 10, and hasn't been successfully attacked as far as I know. That security mitigation has prevented me from building a stable exploit primitive in the past. And reduced the risk rating of a buffer overflow that I found from trivially exploitable, to not exploitable.
These mitigations are worth it, IMO.
There is also some memory overhead:
* AddressSanitizer uses more real memory than a native run. Exact overhead depends on the allocations sizes. The smaller the allocations you make the bigger the overhead is.
* AddressSanitizer uses more stack memory. We have seen up to 3x increase.
* On 64-bit platforms AddressSanitizer maps (but not reserves) 16+ Terabytes of virtual address space. This means that tools like ulimit may not work as usually expected. Static linking of executables is not supported.
It's not as bad as something like valgrind, but it's certainly not something you'd want enabled on every single process.
Please could you explain how ASLR makes your programs impossible to debug?
I'm surprised to hear this, as I work on such executables in my debugger every day, with no problems whatsoever caused by them having ASLR enabled.
> On the other hand, stuff like ASAN is great.
It is, but it's not intended as an exploit mitigation. You typically wouldn't apply it to your binaries running in production, due to the performance hit. Its purpose is to help detect memory safety bugs during development and testing.
This is why personality(2)'s ADDR_NO_RANDOMIZE exists, and both GDB and LLDB use it. And, like, if you have are attaching to an executable that was already launched both debuggers are more than competent enough at reading /proc/pid/maps and rebasing debug symbols to match.
> On the other hand, stuff like ASAN is great. I don't hear many people talking about it, sadly enough, outside Chrome team.
Every major browser engine tests with address sanitizer, as does the Linux kernel and many other projects that are concerned about security–it catches real bugs! But it could always see wider adoption, of course.
> Operating systems should enable that systemically.
But it's not really a security feature, nor is it something that an operating system implements (it's a dynamic library and an instrumented binary). However, memory tagging may bring something similar at the hardware level, and we may actually see real usage of this in the coming years rather than the perpetual soon™.