[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190726203115.GA9939@pi3.com.pl>
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.
