CVE-2016-0728, Practicality, and Going Crazy

A new and very serious Linux kernel exploit affecting Linux kernels 3.8 and later, CVE-2016-0728, was announced today with surprisingly little fanfare.

Perception Point LTD, the company that disclosed the vulnerability, provided an amazing write up which I’ve already linked to. Without going into the questions of responsible disclosure, etc., the write up is one of the very rare ones: professional and succinct, while providing exactly the details needed to understand what is going on.

So why do I find myself surprised that this isn’t more prevalent in the news? This vulnerability, when exploited, effectively gives unrestricted root access and there is no patch available for it yet. The best I can find is a crafty SystemTap patch attached to RedHat’s bug report on the issue; PaX/grsecurity unsurprisingly protects against this, and a comment on the sample code indicating that there is a non-default sysctl value that might provide limited protection at the expense of being able to perform some performance analysis as a regular user. SELinux does provide some protection but it can be bypassed, and Perception Point indicates that they’ll even provide write ups of how they test in follow-up blog posts.

I personally don’t see any harm in recommending that users set the following sysctl values if they have an affected kernel using the following command as root, at least until a proper patch is available. As always, please understand changes you make to your systems and don’t trust every blog post.

sysctl -w kernel.kptr_restrict=1

There is one side of these kinds of vulnerabilities that I don’t see discussed very much in the security industry: practicality of using the attack. When I personally consider exploits like these, I like to think about a couple of different categories, which in my mind map to how they’ll be used. Is it a local or remote vulnerability? How reliable is it? How easy would it be to modify to execute any other arbitrary code? What privileges will my new code have? How likely is it to be patched on a system?

Some of these questions I’ve already answered: the exploit gives full root access, and there is a very small chance that a target is protected against it. As to reliability, the proof of concept code released with the write up works scarily well, though it takes time and resources (about half an hour when I tested it in a virtual machine) and I have yet to see it fail. There also doesn’t appear to be any restriction on the code you’re able to execute with those privileges.

The one redeeming feature of this exploit – and probably why people are not going as crazy over this as some other recent named vulnerabilities  – is that it requires getting the code to run as an already legitimate user. In the parlance of our industry, it is exclusively a privilege escalation vulnerability.

There are a lot of applications out there now running on a matching kernel, and unless you really read that write up you may miss it. This exploit affects Android 4.4 and later. There doesn’t seem to be a working PoC for Android yet but people are already trying to test it and there is nothing special about the Android kernel that will prevent it.

2 replies
  1. Rogers
    Rogers says:

    When it takes about an hour to get it to work on a PC, how long will it take it to work on a much slower Android-phone and how hot will it get? Maybe it will run out of juice before you are able to pwn it? 😉

    Reply
  2. Botch
    Botch says:

    I tested the Perception Point code on linux kernel 4.1.6

    Got the commit_creds and prepare_kernel_cred addresses from /proc/kallsyms

    increfing went fine but at the end I still couldn’t elevate to root

    You did try on a kernel different than 3.18?

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *