Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analysis and Exploitation of a Linux Kernel Vulnerability

perception-point.io

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#31

Post by 16 »

juhanima wrote: post #23
mnw21cam wrote: post #4

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

Arch seems to be kosher $ uname -r 4.3.3-2-ARCH No root: $ ./cve_2016_0728 PP_KEY uid=1000, euid=1000 Increfing... finished increfing forking... finished forking caling revoke... uid=1000, euid=1000 Only took about 25 minutes on a Lenovo core i7. That's kind of scary. EDIT: Actually it seems that atomic_t is 64 bits long with x86_64 these days, so no hope of overflowing.

Arch is not kosher. You need to do this: https://news.ycombinator.com/item?id=10931954

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#32

Post by 16 »

LinuxBender wrote: post #9
tshtf wrote: post #6

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 Premature blog post?

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 a…

You need to update the addresses of commit_creds() and prepare_kernel_cred() as per this: https://news.ycombinator.com/item?id=10931954

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#33

Post by [deleted] »

LinuxBender wrote: post #9
tshtf wrote: post #6

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 Premature blog post?

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 a…

[deleted]

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#34

Post by [deleted] »

LinuxBender wrote: post #9
tshtf wrote: post #6

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 Premature blog post?

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 a…

[deleted]

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#35

Post by Maran »

wfn wrote: post #20
javanix wrote: post #16

Earlier quoted context omitted.

How do you find those addresses?

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;

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?

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#36

Post by javanix »

baghira wrote: post #30
NotHereNotThere wrote: post #29

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$

If you have SMAP, i.e. an Haswell or newer Intel CPU, you should not be vulnerable, so that could be an explanation.

Is SMAP required for mitigation, or is SMEP enough?

IIUC SMEP is on Sandy Bridge processors too.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#37

Post by thefreeman »

NotHereNotThere wrote: post #29

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$

Did you update the addresses of the kernel functions?

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

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#38

Post by heinrich5991 »

corv wrote: post #7
garrettr_ wrote: post #2

This vulnerability is a great advertisement for grsecurity/PaX, which mitigates it at the source of the issue thanks to PAX_REFCOUNT.

Unfortunately no major distributions ship those patches by default.

Arch Linux does: https://www.archlinux.org/packages/?name=linux-grsec

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#39

Post by baghira »

javanix wrote: post #36
baghira wrote: post #30

Earlier quoted context omitted.

If you have SMAP, i.e. an Haswell or newer Intel CPU, you should not be vulnerable, so that could be an explanation.

Is SMAP required for mitigation, or is SMEP enough? IIUC SMEP is on Sandy Bridge processors too.

According the lwn comments it should be sufficient (and the post by perception-point suggests that it would at least make things more difficult), but I haven't the hardware to test for myself.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#40

Post by eloy »

heinrich5991 wrote: post #38
corv wrote: post #7

Earlier quoted context omitted.

Unfortunately no major distributions ship those patches by default.

Arch Linux does: https://www.archlinux.org/packages/?name=linux-grsec

> by default

Arch don't even have coreutils "by default". Yes, I know, you're supposed to install them anyway, but if you follow the standard install guide, there is no GRsec.

Post reply on HN