Hacker News Reader

Comment by irdc | Hacker News Reader

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.

View on HN

> 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.

> 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?

Is this some obscure feature of Windows? In my experience, while code sections are almost never writable, they're always readable.

I was wrong, I was thinking of DEP which is quite different.

32-bit intel ISA supports execute-only memory pages.

Only through segmentation hacks right? In page table entries, execute doesn’t have a separate flag but shares it with read.

execute disable was added with the pentium 4 (but needs pae page tables)

Yes, but execute disable is not the same as execute only. AFAIK there's no way to prevent executable pages from being readable using only the i386/amd64 page table.

You can fudge it with protection keys (poorly), and you can do it for real with EPT tricks.

Only 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)

Is that a security measure? What would execute-only prevent?

Yeah, 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.

There 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.

As 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?

A 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.

Ah, 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.

Yes, 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).

I 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.

execute-only as in no reading?

Reply on news.ycombinator.com