The 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.
Well, 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...
> Well, 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.
Now you got me thinking. That's avoidable on linux - you can use SELinux to disallow the compiler process to execute it's own output. You might be able to ensure that a process is able to execute the compiler xor it's output, but I'm not sure about that. I know the first one because I've spent a weekend writing an SELinux module for our application servers, which don't need to execute anything after a certain startup procedure. But let me tell you, java + SELinux is not for the faint of heart, because the executed binary is shared.
> 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.
I call that trust management for myself. For example, from a systems perspective, my configuration management is a large security issue. It downloads binaries either via a package management or via HTTPs, validates them and runs them. It has to download and run them, because that's the definition of 'provisioning a server'. And it doesn't matter if the binaries are pre-baked via docker / packer, or if chef/puppet install them in VMs on the fly, the entity 'config management' just grows larger.
As such, we have to trust our configuration management, because we have to trust something, because we can't enforce security at this point.
You 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).
UPX is not affected. It sets the appropriate permissions on its pages.
This is the difference between legit and non legit. A legit software can set the permissions. A remote RCE exploit may be able to insert a payload in memory but it won't be able to change permissions.
Could 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.
> 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.
ASLR 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.
> 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...
On both of these platforms, ABIs and APIs are stable until you get to drawing. Which means you should probably use real process separation for the GUI - it has to be linked dynamically.
It is stable in the terms of "actually didn't change in a way to break apps" not "guaranteed to be kept compatible".
Last time they did a major break there is in Windows 2000. I recommend reading up on how LPC works.
There have been extensions though. Such as very useful pico processes in Windows 10...
Major extensions in Vista too, related to security and async operation.
I recommend j00ru's blog as a good starting point. And of course Windows Internals books.
> And no, it does not make dealing with debugging info equipped dumps any harder, as long as walking the stack is all you need.
I didn't quite get that: the core dump is just a dump of (some of) the memory mappings of the dumped process. in my experience gdb often does not manage to make sense of it (with ALSR).
(one replacement strategy is to suspend a faulting process with SIGSTOP so that it is possible to attach to it later on)
For debug equipped binaries, gdb will easily spot code addresses, after walking some stack. The trouble is, if the stack is damaged it ends up being worthless.
