Comments on: partial NX emulation in Ubuntu

By: kees

kees — Fri, 15 May 2009 21:53:22 +0000

brk only when the exec is PIE and doesn’t get mapped at the top of the executable region limit. I assume this is a bug in the vma randomization side of the patch. I’m gonna go switch to email…

By: spender

spender — Fri, 15 May 2009 21:39:18 +0000

brk too even? That shouldn’t happen. Do you build your kernels with COMPAT_BRK=y?

-Brad

By: kees

kees — Fri, 15 May 2009 21:23:46 +0000

BTW, yeah, I can totally reproduce NX-emu-dodging via library bss or via PIE program bss and brk regions. That’s unfortunate. :( Thanks for the heads-up!

By: spender

spender — Fri, 15 May 2009 19:58:50 +0000

Also, to clarify: Solar Designer’s non-executable stack via segmentation came first, then some other misc non-executable stack + heap via segmentation patches (RSX, KNoX), then PaX which was the first exact NX emulation via either segmentation or TLB tricks. It’s all documented on http://pax.grsecurity.net

-Brad

By: kees

kees — Fri, 15 May 2009 19:27:47 +0000

Thanks for the corrections and links! Sure, I’m not claiming it’s perfect, I’m just claiming the patch carried by RedHat is finally in Ubuntu now. It’s better than not having any NX, but like I ended the post with, I’d prefer everyone just use 64bit. :)

By: spender

spender — Fri, 15 May 2009 18:26:57 +0000

Actually, it wasn’t designed by the OpenBSD people; get your facts straight. OpenBSD was *several years* late to the game: PaX was developed in 2000.

As for “NX emulation”, the provided example is highly misleading in the same way that RedHat has been misleading people for years regarding how accurately exec-shield emulates NX.
See:
http://magazine.redhat.com/2007/05/04/whats-new-in-selinux-for-red-hat-enterprise-linux-5/
http://lists.immunityinc.com/pipermail/dailydave/2007-May/004340.html

Say vulnerable-setuid-program has a vulnerability in bounds checking on a buffer in the .data or .bss sections of the main executable or any library loaded by the executable. If that executable/library doesn’t happen to be located highest in the address space (and its probability of not being located there is n – 1/ n, where n is the number of loaded executables/libraries in the process’ address-space) then the vulnerability is still perfectly exploitable as it would be without any NX. If you get unlucky and it does happen to be mapped highest, just repeat the exploit until it succeeds.

But of course, details are unimportant. What matters is claiming you have “NX emulation.”

-Brad

By: mirabilos

mirabilos — Fri, 15 May 2009 10:38:39 +0000

Actually, it was designed by the OpenBSD people as part of the
W^X protection scheme’s adaption to the i386 (and IIRC macppc)
architectures.

By: kees

kees — Fri, 15 May 2009 05:10:37 +0000

That would be up to Debian — the port I did is against a mostly stock upstream Linux kernel. There’s no reason it couldn’t be carried, but that’s up to the Debian kernel maintainers.

By: foo

foo — Fri, 15 May 2009 04:35:09 +0000

So can you push these into Debian too?

By: kees

kees — Thu, 14 May 2009 17:47:22 +0000

Prior to Karmic, if you run 32bit kernels on 64bit machines, you do not get the NX protections. You must be running in “PAE” mode (prior to Karmic only available in the -server 32bit kernel flavor). PAE mode is automatic in 64bit kernels.

Note that even with PAE (or 64bit), you still need NX support in the CPU (some BIOSes turn it off).

By: oliver

oliver — Thu, 14 May 2009 17:33:22 +0000

For clarification: if I run 32bit Jaunty on a 64bit capable processor, is there any kind of NX protection (hardware or software) in use then? Or do I need to run a 64bit installation to get that?