Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 26 Jul 2019 22:31:15 +0200
From: Adam Zabrocki <>
Subject: Re: LKRG 0.7 CI & ED bypass


> Where is this modified POC available?

They are not complicated modifications: I locked the page in the RAM (madvice) 
and reenabled SMEP from the ROP so there is a reduced chance of SMEP 
verification failure.

> ^^^ The lack of proper cleanup after (unlocking of text-mutex) was mentioned in
> my original message. Obviously, it???s wrong to leave it locked forever. But you???ve
> got the idea of how it might be used, albeit this vector is considered as ???known???.

If you unlock text-mutex, then CI would enter the verification state (and catch 
modification and/or SMEP violation) so the cleanup should be smarter. And yes 
that's a 'known' vector.

> Do you really think SMEP is able somehow to prevent the exploitation? All these dances
> around SMEP bypass detection worth nothing in total as finally one can make a pure ROP
> exploitation without even executing a bit of user-space code from the kernel.

I believe you're missing the point of LKRG. Aim of it is not to completely stop 
exploitation process but to make it harder and less reliable. As far as I'm 
aware, all of the anti-exploitation / security technologies (including 
mitigations) follow the same path and are bypassable, e.g.:

 - Firewalls are trivial to bypass, but you still use them
 - Antiviruses are trivial to bypass, but people pay money for them
 - Mitigations:
   - ASLR and KASLR are easy to bypass, but people still want to have it 
enabled in the system
   - NonExecMemory is easy to bypass, but people still want to have it enabled 
in the system
   - SMEP is easy to bypass, but people still want to have it enabled in the 
   - StackCookies are bypassable but people still compile binary with them
   - RelRO are bypassable but people still enable that flag
   - more
 - Any anti-thread technology (e.g. Capsule8/Crowdstrike/WDATP/much more) are 
trivial to bypass or can be completely disabled (some of them run in user-mode) 
but people pay a lot of money to use them.

LKRG is no different here, except for the "price" part, since many of these 
technologies are not free.
Without LKRG you can just overwrite credentials and don't even need to execute 
any kernel code. Now we are speaking about pure-ROP only exploit, which needs 
to race witch scheduler, pCFI and take care of leaving the kernel in a clean 
state. Depending on the bug, it might be easier, but there are some of the bugs 
which can never be exploitable under LKRG (e.g. any 'swapgs' group of bugs, 
like BadIRET, SysRet, PopSS, etc.).

LKRG is evolving and improving also thanks to your research, e.g. LKRG could 
stop latest container escape because we added UMH hardening. Even if I do not 
approve the form or attitude of communication, I am grateful for your work.

Best regards,

pi3 (pi3ki31ny) - pi3 (at) itsec pl

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.