[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Jul 2019 10:34:39 +0400
From: Ilya Matveychikov <matvejchikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG 0.7 CI & ED bypass
> On Jul 21, 2019, at 11:48 PM, Adam Zabrocki <pi3@....com.pl> wrote:
>
> Hi,
>
> On Sun, Jul 21, 2019 at 11:19:56PM +0400, Ilya Matveychikov wrote:
>> Hello,
>>
>> Nice to see LKRG version 0.7 here, I wonder it is still alive.
>>
>> This time I???d like to use a CHAIN!!11 of 2 by-design bugs in LKRG to
>> show how to bypass both CI and ED:
>>
>> - (1) bypass of CI by locking a ???text_mutex??? which makes CI stuck on
>> acquiring it, so no CI will be performed
>> - (2) bypass of ED by patching kprobes dispatcher function (get_kprobes),
>> so LKRG-hooks will not be triggered by kprobes
>>
>> Unfortunately, don???t have much time to do proper cleanup for this but as
>> usual I???ve published some code on github so anyone can play with:
>>
>> https://github.com/milabs/kernel-exploits/commits/lkrg0.7-bypass
>>
>> Also, I don???t know how good LKRG SMEP protection is as I don???t have a proper
>> device to make tests but as far as I can see SMEP protection (as well as WP once)
>> is also kprobes-based, so I???m guessing this approach will defeat it as well.
>>
>> Did I miss something?
>>
>
> I've verified your code on a 2 different devices a few times and the current
> LKRG logic is 'faster' and kills it correctly:
>
...
> [Sun Jul 21 12:42:45 2019] [p_lkrg] ALERT !!! _STEXT MEMORY BLOCK HASH IS
> DIFFERENT - it is [0xd1a1315dcc0fb3eb] and should be [0x63c62b27e26ab3d7] !!!
> [Sun Jul 21 12:42:45 2019] [p_lkrg] ALERT !!! SYSTEM HAS BEEN COMPROMISED -
> DETECTED DIFFERENT 1 CHECKSUMS !!!
> [Sun Jul 21 12:42:45 2019] [p_lkrg] <Exploit Detection> SMEP was disabled!
> Enforcing SMEP now!
>
> In case of locking global kernel text_mutex you will not only block LKRG but
> kernel itself. Idea is correct and we have documented this limitation in our
> presentation here:
>
> https://www.openwall.com/presentations/CONFidence2018-LKRG-Under-The-Hood/slide-39.html
>
CI timer is a periodic job with 15 seconds period by default so I don’t see the reason why
it isn’t possible to launch the exploit when CI is not yet started. Lucky you, but it works
well on my VM :-)
Anyways, there are a lot of data-only attacks which might be used to attack the kernel and
mostly all of them (known to me) requires to have just AAW primitive which in turn requires
a simplest ROP-chain like “pivot // mov r1, val // mov r2, adr // mov [r2], r1”. So, as
you can see no SMEP is affected by such kind of chain at all.
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.
