User: Password:
|
|
Subscribe / Log in / New account

Attacking hardened Linux systems with kernel JIT spraying

Attacking hardened Linux systems with kernel JIT spraying

Posted Nov 19, 2012 19:53 UTC (Mon) by nybble41 (subscriber, #55106)
In reply to: Attacking hardened Linux systems with kernel JIT spraying by farnz
Parent article: Attacking hardened Linux systems with kernel JIT spraying

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.


(Log in to post comments)

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 (subscriber, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds