5 ms·
Tricks like these are going to become less common with execute-only mapping of .text slowly proliferating through the industry (iOS, OpenBSD). Though i386 is u
by irdc 3y ago
Tricks like these are going to become less common with execute-only mapping of .text slowly proliferating through the industry (iOS, OpenBSD).
Though i386 is unlikely to ever become execute-only.
- H8crilA 3y agoIs that a security measure? What would execute-only prevent?
- irdc 3y agoYeah, it makes constructing ROP chains slightly more difficult when combined with ASLR and the like as you cannot defeat the randomisation by inspecting the running binary.
- H8crilA 3y agoAs in you already roughly know where code is mapped, but need the lower bits of the offset? Or also to learn the specific version of the running code?
- irdc 3y agoA successful ROP attack requires the exact addresses of the various gadgets used (refer to a definition of ROP if this is unclear, as I’m currently on mobile). ASLR thwarts this, as does the libc layout randomisation that OpenBSD does on every boot. However, it’s not perfect, and if you can read program memory you could scan for gadgets at run-time. This last point is prevented by execute-only.
- H8crilA 3y agoAh, but you first need to have even an approximate idea of where some code is mapped, otherwise you'll fault on nearly all requests into a 64 bit space.
- irdc 3y agoYes, that’s true. That’s where infoleaks come in. Plus a lot of crashes are likely not even noticed, or blamed on the software just being buggy. Repeatedly crashing a fork()‘ing server might just give you enough information to reconstruct its memory layout (which doesn’t vary between parent and child processes after a fork(), which is why OpenSSH does an execve() of itself after fork()’ing).
- H8crilA 3y agoI see, but for a 1GiB mapped code space we're talking here about 2^64/(1 Gi) = 17'179'869'184 attempts, or perhaps about half of that with average luck.
- Findecanor 3y agoThere are also attacks such as "JIT spraying" where JIT-compiled code contains large constants that the runtime gets tricked into jumping into. Execute-only would make that attack a little less likely.
- PrimeMcFly 3y ago> Tricks like these are going to become less common with execute-only mapping of .text slowly proliferating through the industry (iOS, OpenBSD). Give the PaX project some credit, since they had it before OpenBSD did. Windows has had it for a while also, since XP.
- taway1237 3y agoIs this some obscure feature of Windows? In my experience, while code sections are almost never writable, they're always readable.
- PrimeMcFly 3y agoI was wrong, I was thinking of DEP which is quite different.
- irdc 3y ago> Give the PaX project some credit, since they had it before OpenBSD did. I didn’t know that and cannot find anything that confirms this. You have a source?
- adastra22 3y ago32-bit intel ISA supports execute-only memory pages.
- irdc 3y agoOnly through segmentation hacks right? In page table entries, execute doesn’t have a separate flag but shares it with read.
- blibble 3y agoexecute disable was added with the pentium 4 (but needs pae page tables)
- Findecanor 3y agoOnly through segmentation, I think. However x86-S is supposed to force a flat memory model for 32-bit programs as well. On recent Intel processors, it is possible to execute-only protect pages using Intel MPK (Memory-Protection Keys) by having pages with a key be read-only in the page table but "access disable" in the PKRU register. PKRU is accessible from user mode though. AFAIK, the only (still) mainstream CPU arch with reliable execute-only protection is RISC-V. (I would like to be wrong, and see it on e.g. ARM as well)
- ehaliewicz2 3y agoexecute-only as in no reading?