4 ms·
Hardening C/C++ Programs – Executable-Space Protection and ASLR
- ctz 9y agoAlternate title: "It's Probably Fine: Continuing to Ship Unsafe Programs by Pretending ROP Doesn't Exist".
- mrich 9y agoCould you be a bit more specific? As can be seen from the article, this is one part of a series describing several best practices you should follow when shipping binaries. This one article does not claim to cover everything. Also check part 1 and the upcoming ones. Also, if there is a defense against ROP and other exploits that makes it possible to do away with ASLR and ESP please let me know.
- ctz 9y ago> Also, if there is a defense against ROP and other exploits that makes it possible to do away with ASLR and ESP please let me know. Memory safety. Everything else (ASLR, DEP, CFI, heap hardening, etc.) is just fiddling around the edges -- it's not an engineering approach that produces reliable or safe software.
- mrich 9y agoAgreed; but until we get there, we must make sure the software we ship from existing codebases is as safe/unexploitable as possible.
- MichaelMoser123 9y agoROP has problems with ALSR on 64 bit machine. Security is not a binary on off thing. The harder you make it for the attacker, the better. (however ALSR makes it difficult to deal with core dumps, ouch)
- AstralStorm 9y agoASLR often makes it a requirement to get data disclosure (heap layout or at least GOP) before a full break. A funny thing is that a fully static LTO processed and inlined app is extremely hard to crack once ASLR is in play since you get no returns and get to mess only with what is inside. (Unless you find some dlopen, exec or system, perhaps mmap with unsafely handled flags.) Add good NX and read only pages and it becomes a real puzzle. And no, it does not make dealing with debugging info equipped dumps any harder, as long as walking the stack is all you need.
- pcwalton 9y ago> A funny thing is that a fully static LTO processed and inlined app is extremely hard to crack once ASLR is in play since you get no returns and get to mess only with what is inside. How often does that actually happen? On macOS and Windows the answer should be "never" since the syscall ABI is not stable...
- gok 9y ago> On macOS and Windows the answer should be "never" since the syscall ABI is not stable... Dear Golang...
- user5994461 9y ago#define WINAPI __stdcall The windows API ABI is stable and unchanged for decades.
- AstralStorm 9y ago
- MikeHolman 9y agoCET is coming out soon, and I'm hopeful that this will make ROP much harder.
- mrich 9y agoHadn't heard about that one before, here are more details: https://software.intel.com/en-us/blogs/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks https://software.intel.com/en-us/blogs/2016/06/09/intel-rele...
- stcredzero 9y agoNeeds much better editing!
- tetha 9y agoThe executable space protection seems like a more general basline pattern: An entity should either be able to write or modify something, or execute it. If it can do both, that's a possible security issue. This holds true for memory pages, files on a file system and with some stretches even to firewalls and security groups.
- knome 9y agoSuch an ultimatum would falls afoul of modern JIT compilation, however.
- AnimalMuppet 9y agoWell, it falls afoul of compilers. JIT compilation does it in memory, but a regular compiler breaks the same rules on disk - it writes a file that is executable. But even if we were writing binaries by hand, the editor that wrote them would still be breaking the same rules. There's no getting around it. The stuff that creates executables has to break those rules. You just want a very limited set of things that are able to do that. Even in JIT, the JIT portion of the runtime should be able to write executable pages of memory, and the rest should not be able to. But how do you enforce that? Aye, there's the rub...
- MikeHolman 9y agoYou can do this with an out of process JIT. Basically the JIT process has the code mapped as read/write and maps it into the runtime process as read/execute. Then you can use OS capabilities to prevent the runtime process from creating its own executable pages (on Windows you can do this by enabling ACG).
- cwzwarich 9y agoAn out-of-process JIT would be too slow for optimizations like inline caches.
- 9y ago