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" , 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 . > > > > > > : https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html > > > : > > > 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.