[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 3 Jul 2021 02:42:19 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Adam Zabrocki <pi3@....com.pl>, Solar Designer <solar@...nwall.com>,
lkrg-users@...ts.openwall.com
Subject: Attacking LKRG v0.9.1
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].
Best regards,
Alexander
[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/
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.
