Date: Fri, 26 Jul 2019 22:31:15 +0200 From: Adam Zabrocki <pi3@....com.pl> To: lkrg-users@...ts.openwall.com Subject: Re: LKRG 0.7 CI & ED bypass Hi, > 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 system - 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, Adam -- pi3 (pi3ki31ny) - pi3 (at) itsec pl http://pi3.com.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.