
Analysis and Exploitation of a Linux Kernel Vulnerability - ddb
http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/
======
garrettr_
This vulnerability is a great advertisement for grsecurity/PaX, which
mitigates it at the source of the issue thanks to PAX_REFCOUNT.

~~~
corv
Unfortunately no major distributions ship those patches by default.

~~~
eloy
Why don't they? There are not that much performance downsides to
PaX/grsecurity AFAIK. And it doesn't break the ABI monthly like OpenBSD does.
(Don't get me wrong, I like OpenBSD personally, but this is not suitable for
enterprises)

I don't agree with Torvalds, but at least I can understand him. I don't
understand why distros don't implement it.

[http://www.washingtonpost.com/sf/business/2015/11/05/net-
of-...](http://www.washingtonpost.com/sf/business/2015/11/05/net-of-
insecurity-the-kernel-of-the-argument/)

~~~
baghira
While the fact that since last fall grsecurity only ships the stable branch of
the patchset for sponsors (because of persistent trademarks violations)
doesn't help integration in smaller distributions (also Debian, I would
guess), I am always baffled as to why grsecurity/Pax were never chosen by a
distro like Suse to differentiate itself from Red Hat.

------
rolandr
Can anyone identify a patch to apply to existing kernels to fix this? Are
there any released 3.8+ versions that are not vulnerable? The "mitigations"
section at the end is not forthcoming about this. Vulnerable systems remain
vulnerable without such information.

This does not seem to be a responsible disclosure of the vulnerability (keep
in mind it was posted on their blog 5 days ago).

------
mnw21cam
Well, the exploit doesn't seem to work on my kernel 4.1.0 system, so that's
good.

~~~
16
Did you update the addresses of commit_creds() and prepare_kernel_cred() to
match your running kernel before you compiled/ran it?

~~~
javanix
How do you find those addresses?

~~~
wfn
By looking at _/ proc/kallsyms_:

    
    
      grep commit_creds /proc/kallsyms
      grep prepare_kernel_cred /proc/kallsyms
    

Then update addresses as shown in one of the code snippets:

    
    
      _commit_creds commit_creds = 0xffffffff81094250;
      _prepare_kernel_cred prepare_kernel_cred = 0xffffffff81094550;

~~~
Maran
Question for you.

As a normal user, grepping these values I actually get 0000000000000000. I
can't imagine these being the actual values. Is it possible that because I
remount my /proc with the hidepid=2 option the values are not visible for
normal non-root accounts?

~~~
baghira
That only hides the pid directories of others users, and indeed on my system
remounting /proc with hidepid=2 I'm still able to see the same values for
kallsyms. Maybe your kernel is compiled without the CONFIG_KEYS=y option? (I'm
spitballing here).

~~~
Maran
It is indeed compiled with CONFIG_KEYS=y. Does this protect me against this
issue? I'm not sure what this means.

~~~
baghira
No, the bug is in the kernel keyring facility, so if I'm not mistaken
compiling with CONFIG_KEYS=n option should protect you (I haven't tested
though). As for the /proc/kallsyms, I honestly don't know how come you only
get zeroes.

EDIT: The obvious question I should have asked is which distro you are
running. Also, as others have pointed out, hoping that the attacker can't read
kallsyms from the machine he's attacking is not really a good defense plan.

~~~
Maran
I'm running Ubuntu 14.04 which should be affected. I just hoped it would be
harder without having the correct kallsyms version. It seems I will have no
options except to reboot my cluster :)

------
geofft
Is there a reason that there's no overflow check on these refcounts? I suppose
it's something like, these are hot paths in general and there's no good
hardware support for atomic-increment-if-not-overflow?

~~~
topspin
The path can only be so 'hot'... any given cryptographic operation using the
artifacts maintained by this `keyring' system will be many orders of magnitude
greater than an overflow check on allocation, hardware support or not. I think
we're left to conclude this is just another instance of naive C programming.

------
tshtf
The blog post specifically thanks the Red Hat Security Team, but according to
the Red Hat Bugzilla, no patch has been released yet for RHEL/CentOS:

 _This issue affects the Linux kernels as shipped with Red Hat Enterprise
Linux 7 and will be addressed in a future update._

[https://bugzilla.redhat.com/show_bug.cgi?id=1297475](https://bugzilla.redhat.com/show_bug.cgi?id=1297475)

Premature blog post?

~~~
LinuxBender
Tested on CentOS 7, fully patched.

    
    
        [ohadmin@localhost shm]$ ./cve_2016_0728 PP_KEY
        uid=99990, euid=99990
        Increfing...
    

This is taking a long time. I disabled SELinux and it has been cranking away
for a while now.

    
    
        PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
        1140 ohadmin   20   0    8428    388    296 R 100.0  0.0   9:25.17 cve_2016_0728
    
    

No need to test on CentOS 6. Forgot how ancient that kernel is.

 _Update:_ I am not having any luck getting this to work on CentOS 7. I even
completely disabled SELinux (selinux=0 vs setenforce 0) Anyone else getting
this to work?

~~~
ryanlol
That's not how you execute binaries, just "./cve_2016_0728 PP_KEY" is the
correct syntax

~~~
LinuxBender
Yes sorry. I will make the cheap excuse that I am recovering from food
poisoning and don't quite have it all together. Thankfully I don't manage
nuclear weapons, so we are all safe for now.

------
tkinom
Would a properly setup SELinux able to capture a local program that exploit
this kind of bug?

Is there any other other of Linux/Mac/Windows/Android dist that have some type
of security framework capture this kind of issue?

~~~
baghira
As others said, using a kernel with the Grsecurity patchset would prevent the
issue (I believe the configuration of SElinux on Android should be sufficient,
but the default config in RHEL7/Fedora is insufficiently strict).

------
cmurf
Fedora is currently building a 4.3.3-X for F22 and F23 that includes a fix.

------
pearjuice
To me it's kinda baffling that an open source project so intensively used had
a root privilege exploit for years. It is often said that open source is
inherently more secure because "everyone can look at the source" yet quite a
few exploits in in the last few years alone kindly proved the opposite.

This is not a jab at open source software, just at the general statement which
people like to throw around when referring to the security of open source
software; "It's open so it must be safe!"

~~~
redahs
Open source is inherently more secure then closed source, not because of how
the code is written and reviewed, but because of how the code is published and
distributed.

Suppose we have two projects with 100% identical source code, which are
mathematically proven to both contain 0 bugs, and which have been extensively
audited by third parties.

Despite being identical, the open source version will be much more secure for
end users, because the source code and machine code can be obtained, compiled
and distributed by a much larger number of competing parties.

This allows users to compare compiler output and run-time behavior, to verify
that software being run is actually the software being written, and to ensure
that the software is not surreptitiously modified by the publisher during its
distribution.

With closed source software, even if developers write a 100% perfect codebase,
the end users have no way of knowing whether they are actually getting that
specific code base in their binaries, as there are legal and technical
barriers in place preventing them from reliably making that verification for
every change.

~~~
chatmasta
What about the corollary to that? Open source code is more accessible than
closed source code, not only to reviewers, but also to vulnerability hunters.
For every honest reviewer, there can be a malicious one. Also consider the
profit incentives are stronger for malicious reviewers than they are for
friendly ones.

~~~
5ilv3r
The National Institute of Standards and Technology (NIST) in the United States
specifically recommends against this practice

[https://en.wikipedia.org/wiki/Security_through_obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity)

------
5ilv3r
Has the demo code actually worked for anyone?

~~~
vnik
I'd be surprised if this code actually gives #. it would be like winning a
lottery :)

~~~
5ilv3r
I'm not big on patching needlessly. Guess I'll have to wait for a better
tester.

------
NotHereNotThere
Did not get root on my test box (OpenSuSE 13.2 64bit) with kernel
3.16.6-2-default

    
    
      uid=10000, euid=10000
      Increfing...
      finished increfing
      forking...
      finished forking
      caling revoke...
      uid=10000, euid=10000
      sh-4.2$

~~~
thefreeman
Did you update the addresses of the kernel functions?

    
    
        #define COMMIT_CREDS_ADDR (0xffffffff81094250)
        #define PREPARE_KERNEL_CREDS_ADDR (0xffffffff81094550)

~~~
vnik
even if you don't update the addresses you would at least get an oops if the
exploit is working. I've explained the problem with rcu calls in my post
[https://cyseclabs.com/page?n=02012016](https://cyseclabs.com/page?n=02012016)
reply but did not describe the technique for ordering these calls. The way
they do things in the poc, you'd be lucky if it succeeds once out of 100.

