Skip to content
LKRG bypass methods
C Makefile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
001-call_usermodehelper Move all shell stuff to shell/ folder Jan 8, 2020
002-simple_setattr
003-direct_inode_manipulation Move all shell stuff to shell/ folder Jan 8, 2020
004-cfi_bypass Real pCFI bypass Jan 8, 2020
005-call_usermodehelper_ld_preload Real pCFI bypass Jan 8, 2020
006-kprobes_disable
007-direct_inode_manipulation_2 Added 007-direct_inode_manipulation_2 Jan 8, 2020
CVE-2017-1000112 CVE-2017-1000112 imported Jan 7, 2020
shell Cleanup shell.c Jan 8, 2020
README.md

README.md

lkrg-bypass

The repository contains set of methods which I consider to be useful to test LKRG protection against exploitation.

The history of researching of such methods started a year back with my the very first comment to LKRG community of how I see the LKRG protection can be bypassed:

There were few more discussions later:

Even though it was stated that LKRG is bypassable by design the project continues to be developed by it's main contributor Adam Zabrocki.

Personally, I found the LKRG source code very well written and I consider it as a great engineering project wich has an amazing integration into the low level kernel's stuff. I really appreciate Adam's effort he put to develop the project. It's an amazing example of how it's possible to develop a high quality out-of-tree kernel module which has so deep kernel integration.

The repository is organized as a set of methods which I developed while I was playing with LKRG. The following pre-conditions were considered:

  • CVE-2017-1000112 exploit was used as a test sample base (cc: @xairy)
  • Ubuntu 16.04.4 LTS with kernel 4.8.0-53-generic was used as a test box along with vagrant (vbox)
  • SMAP/SMEP bypass was not considered to be in the scope of the exploit

Here I have to say few words about SMAP/SMEP. I'm pretty sure that of two features only one makes sense: SMAP. SMEP it's not a big deal and it has nothing against the ROP which is widely used by exploits. So, let's not consider SMEP as a problem at all because it's possible to make the exploitation without execution the code from user-mode address space. SMAP is the only valuable security feature of the CPU but the exploitation can be done without touching the user space from the context of the kernel. In other words, it's possible to have a ROP chain reliably delivered to the kernel without the need of bypassing SMAP. Again, let's put it out of the scope at least now.

You can’t perform that action at this time.