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.