Attacking hardened Linux systems with kernel JIT spraying
Attacking hardened Linux systems with kernel JIT spraying
Posted Nov 19, 2012 2:07 UTC (Mon) by alison (subscriber, #63752)Parent article: Attacking hardened Linux systems with kernel JIT spraying
Posted Nov 19, 2012 2:36 UTC (Mon)
by aliguori (subscriber, #30636)
[Link] (7 responses)
It presumes that you have found *another* explicit that allows you to set the RIP while in kernel mode to an arbitrary address. To demonstrate this, they created a kernel module that let userspace do this. They effectively created their own exploit.
SMEP is a new x86 feature that improves security by preventing the kernel from writing to userspace address spaces that it doesn't explicitly allow itself to write to. Kernel exploits typically rely on redirecting RIP to a userspace address since you can easily put your target exploit code in userspace.
This blog post points out that JITs allow userspace to generate executable kernel space areas that could be used by future exploits to get around SMEP.
SMEP support in Linux is still very new. The hardware won't be out for a long time. I suspect there's clever ways to work around this sort of problem. There's no doubt though that SMEP improves security though as generating uploading BPF routines is certainly a privileged (and restricted) capability.
I don't know what the JIT you refer to is, but if it's in userspace, it's totally unrelated to what's discussed here. If it's a kernelspace JIT, then it's likely the same trick could be done.
Posted Nov 19, 2012 2:51 UTC (Mon)
by alison (subscriber, #63752)
[Link] (1 responses)
Posted Nov 19, 2012 3:03 UTC (Mon)
by aliguori (subscriber, #30636)
[Link]
There's no DOS happening here. The "spraying" part of this is just duplicating the BPF program as many times as possible in order to increase the likelihood of guessing a valid kernel address of the executable. Duplicating the JIT'd code is completely valid behavior.
Making sure JITs use bounded amounts of memory, don't generate infinite loops, etc. is pretty standard stuff.
From what I can tell, Renderscript is completely userspace. I would hope it doesn't allow for malicious generate GPU routines... That would be a pretty serious oversight.
Posted Nov 19, 2012 5:35 UTC (Mon)
by Arach (guest, #58847)
[Link]
Actually, only from executing native code from userspace. What also prevents read/write access is SMAP: https://lwn.net/Articles/517475/
Posted Nov 19, 2012 5:40 UTC (Mon)
by gmatht (guest, #58961)
[Link]
Posted Nov 19, 2012 9:17 UTC (Mon)
by deepfire (guest, #26138)
[Link]
Actually, Ivy Bridge CPUs have been widely deployed for quite some time already, if we're talking about SMEP -- execution prevention.
It is true, though, that /SMAP/ deployment will have to wait until Haswell ships.
Posted Nov 19, 2012 13:23 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Nov 19, 2012 15:22 UTC (Mon)
by arjan (subscriber, #36785)
[Link]
SMEP has one objective, and it meets that. It is not, and nobody every claims it is, the be all and end all of preventing kernel exploits.
The road to a more secure system is one of many small steps... both on the "prevent bugs from happening via tools" side as well as the "make it harder to turn a bug into a successful exploit" side.
Attacking hardened Linux systems with kernel JIT spraying
Attacking hardened Linux systems with kernel JIT spraying
Attacking hardened Linux systems with kernel JIT spraying
Attacking hardened Linux systems with kernel JIT spraying
> from writing to userspace
SMEP prevents execution.
Attacking hardened Linux systems with kernel JIT spraying
Attacking hardened Linux systems with kernel JIT spraying
There's no doubt though that SMEP improves security though as generating uploading BPF routines is certainly a privileged (and restricted) capability.
In the presence of BPF seccomp filters, not as privileged and restricted as all that.
Attacking hardened Linux systems with kernel JIT spraying
Nothing is.
You need both sides to succeed...