| |||||||||||||
Attacking hardened Linux systems with kernel JIT sprayingAttacking hardened Linux systems with kernel JIT sprayingPosted Nov 19, 2012 18:19 UTC (Mon) by farnz (guest, #17727)In reply to: Attacking hardened Linux systems with kernel JIT spraying by bersl2 Parent article: Attacking hardened Linux systems with kernel JIT spraying
I wouldn't bet on it being impossible if you required aligned instructions, personally. There are some very bright people working in the field of exploiting bugs, and while it may be easier to demonstrate with x86's variable length unaligned instructions, those people will be looking for a way to make it fail on other architectures of interest.
(Log in to post comments)
Attacking hardened Linux systems with kernel JIT spraying Posted Nov 19, 2012 19:53 UTC (Mon) by nybble41 (subscriber, #55106) [Link]
The real problem is being able to branch in to the middle of a JIT module. It should only be possible to call the beginning of a top-level function.
One way to ensure that (though it may come with unacceptable overhead) would be to initially mark the pages containing the JIT code as non-executable, and check the exact address causing the exception whenever something branches to it. The page would need to be marked non-executable again when the JIT code is finished, and there would be a small window of opportunity while the code is executing.
The other option, of course, is to run JIT code in one or more dedicated, high-priority user-mode threads rather than calling it directly from kernel mode. Naturally, this would add the overhead of two context switches to each JIT call, which may also be unacceptable.
Attacking hardened Linux systems with kernel JIT spraying Posted Nov 19, 2012 20:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Page faults are WAY too costly for that.
Attacking hardened Linux systems with kernel JIT spraying Posted Nov 19, 2012 20:51 UTC (Mon) by nybble41 (subscriber, #55106) [Link]
> Page faults are WAY too costly for that.
Understood, though surely it must depend on what the JIT module is being used for? Page fault can't be _too_ costly given that they're used for copy-on-write, stable pages, lazy initialization, certain forms of I/O mapping, and IIRC some forms of system call, but of course the whole point of using interpreted byte code or a JIT in kernel mode is to avoid as much overhead as possible.
As an alternative to running a full userspace helper process, a page fault would probably be acceptable. As an alternative to waking up the application to do it's own packet filtering, as in BPF, you're probably right that it's too high.
Attacking hardened Linux systems with kernel JIT spraying Posted Nov 19, 2012 20:54 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
in the case of copy-on-write and lazy initialization, the page fault is accepted because of two things.
1. the work that needs to be done is significant enough that the page fault cost is relatively small in comparison.
2. In a very large percentage of cases, the page fault never happens, and so both the page fault and the initialization are avoided.
In the case of JIT modules, the page fault is expensive compared to the work being done, and the probability of triggering the page fault is high.
|
|||||||||||||