[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210826132517.GA15740@pi3.com.pl>
Date: Thu, 26 Aug 2021 15:25:17 +0200
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: Re: Attacking LKRG v0.9.1
Thanks for your research Alexander and thanks Stuart for the recommendation.
Together with Solar Designer and Alexander Popov we discussed via email various
defense ideas. A temporary mitigation may be setting lkrg.hide=1.
As a long-term solution we are working on a "ring -1" enhancement and a
design of it can be found here:
http://site.pi3.com.pl/priv/TZ-LKRG.txt
However, because of the lack of time this work is moving slowly.
Thanks,
Adam
On Thu, Aug 26, 2021 at 01:36:01PM +0100, IT Offshore wrote:
> To help mitigate this attack in the meantime set:
>
> kernel.kptr_restrict = 2
>
> (this is the default in linux-hardened)
>
> [~/build]$ sudo grep -w "_text" /proc/kallsyms
> 0000000000000000 T _text
>
> Stuart.
>
> On 26/08/2021 11:54, Alexander Popov wrote:
> > On 03.07.2021 02:42, Alexander Popov wrote:
> > > Hello!
> > >
> > > In April I published the article "Four Bytes of Power: Exploiting CVE-2021-26708
> > > in the Linux kernel" [1], where I explained how to exploit it for local
> > > privilege escalation on Fedora 33 Server for x86_64, bypassing SMEP and SMAP.
> > >
> > > Then I improved my PoC exploit to bypass the LKRG protection. I've already
> > > disclosed the details of my experiments to Adam Zabrocki and Solar Designer. And
> > > in this public email, I'll shortly describe the LKRG weaknesses that must be fixed.
> > >
> > > I see two functions in LKRG that are critical for its security functionality:
> > > 1. p_cmp_creds()
> > > 2. p_check_integrity()
> > > Patching the code of these functions makes LKRG helpless; it can't detect
> > > illegal elevation of privileges and kernel code modification.
> > >
> > > Moreover, lkrg.hide is set to 0 by default, which allows attackers to find these
> > > LKRG functions easily using kallsyms_lookup_name().
> > >
> > > On one hand, hiding the LKRG module can make the attacks against the LKRG code
> > > harder. On other hand, hiding the LKRG module might make system administration
> > > harder as well. Hidden LKRG looks like a typical kernel rootkit :)
> > >
> > > Maybe the public discussion in this mailing list will help to find a compromise
> > > and remove my attack vectors. I will tell all the details about my experiments
> > > with LKRG at the ZeroNights conference in August [2].
> > >
> > > [1]: https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html
> > > [2]:
> > > https://zeronights.ru/en/reports-en/improving-the-exploit-for-cve-2021-26708-in-the-linux-kernel-to-bypass-lkrg/
> > Hello!
> >
> > I've published the detailed article about my attack:
> > https://a13xp0p0v.github.io/2021/08/25/lkrg-bypass.html
> >
> > Best regards,
> > Alexander
--
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.
