PAPER: Securing The Kernel via Static Binary Rewriting and Program Shepherding

Posted On // 2 comments
ABSTRACT

Recent Microsoft security bulletins show that kernel vulnerabilities are
becoming more and more important security threats. Despite the pretty
extensive security mitigations many of the kernel vulnerabilities are
still exploitable. Successful kernel exploitation typically grants the
attacker maximum privilege level and results in total machine
compromise.

To protect against kernel exploitation, we have developed a tool which
statically rewrites the Microsoft Windows kernel as well as other kernel
level modules. Such rewritten binary files allow us to monitor control
flow transfers during operating system execution. At this point we are
able to detect whether selected control transfer flow is valid or should
be considered as an attack attempt. Our solution is especially directed
towards preventing remote kernel exploitation attempts. Additionally,
many of the local privilege escalation attacks are also blocked (also
due to additional mitigation techniques we have implemented). Our tool
was tested with Microsoft Windows XP, Windows Vista and Windows 7 (under both virtual and physical machines) on IA-32 compatible processors. Our apparatus is also completely standalone and does not require any third party software.


LINK TO THE PAPER:
http://www.piotrbania.com/all/articles/pbania-securing-the-kernel2011.pdf



Some initial working results in form of video/picture:
1) http://piotrbania.com/all/trash/q_vs_ms10-073.png
2) http://vimeo.com/22189008

2 komentarze:

QuantumG said...

Neat. Can you detect when a func is called via a ret? Or via a static call that should go elsewhere?

Piotr Bania said...

Thanks. Right now I'm only testing whether the destination resides in a executable space that is a part of a loaded kernel module. Regarding the static call you mean a case when a typicall call rel (ia-32 5bytes) is overwritten by the attacker? If so, nope I can't protect against such changes. On the other hand it is generally hard for the attacker to make such changes (plus we are making this even harder). There are of course some other protection ideas I have in mind (some mentioned in the Future Work) but they are far from being implemented at this moment.

- pb