Latest and greatest PoC CVE-2016-0728 not working?

by Vitaly Nikolenko

Posted on January 22, 2016 at 11:38AM

vnik@ubuntu:~$ ./cve-2016-0728 blah
[+] uid=1000, euid=1000
[+] Increfing...
[+] Finished increfing
[+] Forking...
[+] Finished forking
[+] Caling revoke...
uid=1000, euid=1000

So you've tried the PoC(waiting for approximately 30-60 min depending on your CPU) to check whether your system is vulnerable and the exploit that "imperils tens of millions of PCs, servers, and Android phones" didn't work for you? It's amazing how news can stretch the truth for a story.

People are talking about SMEP/SMAP and these being the reasons for the exploit not working. So let me get this straight: even if your CPU supports SMEP/SMAP or your have incorrect addresses for prepare_kernel_cred() and commit_creds(), you would see a page fault, double fault, or some kind of oops (assuming this a working exploit code). In some cases, (depending on the address the kernel execution flow is redirected to), your system may recover after the oops or double fault and require a restart.

The truth is refcounter overflows can be somewhat tricky to exploit due to the RCU implementation and ordering these RCU calls. I've described this problem in my post. I believe this was the first refcounter overflow exploit. However, I didn't describe the technique for ordering these RCU calls to achieve a reliable counter overflow, i.e., counter decrement followed by the null check and free. The exploitation was a bit more complicated since the vulnerable object had no function pointers and was heavily used by the OS, so we had to resort to the SLUB free pointer manipulations.

The point is this vulnerability can be exploited (and the exploitation process can be made somewhat reliable) but not with the provided PoC where they're trying to order RCU calls with sleep()s :) The PoC was apparently tested by Perception Point on 3.18 64-bit. This PoC may have worked for Perception Point in a controlled environment with a debugger attached.

The question for most admins now is how to protect against this bug if there are no patches available yet? Install and configure grsecurity. I'm sure will see more refcounter overflow exploits in the near future, so it's a good idea to enable grsecurity even if your kernel is not vulnerable.

P.S.: Please stop saying this a remote threat that affects millions of Android devices.


  • » Jeremy Huang: I modified the exploit to work successfully.
    • » vnik: hmm. I don't see much difference besides rearranging their binary search braindead logic and changing the commit_creds() and prepare_kernel_cred() addresses. You're still using the sleeps to order these RCU calls. How realiable is this though? say out of 5 runs.
  • » Chris: I was wondering if ASLR can prevent this. Of course the attacker can construct a ROP/JOP chain to bypass ASLR but does it affect it?
    • » vnik: Hi Chris, kASLR makes it a bit more difficult to exploit but there're plenty of kernel address leaks. I know at least 2 public ones discovered in the last month or so. That being said, kASLR is not the solution here and I don't think ROP is used to bypass ASLR :)