Live data from Hacker News

Analysis and Exploitation of a Linux Kernel Vulnerability

perception-point.io

11–20 of 70 posts

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#11
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…

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

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#12
post #8
post #7

Earlier quoted context omitted.

Unfortunately no major distributions ship those patches by default.

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-...

Distributions prefer to minimize divergence from upstream, and therefore tend to avoid non-upstreamed patches.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#13
post #10

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?

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).

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#14
post #10

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?

Yes.

Well, Android and most RHEL-derivated distros use SELinux and it can mitigate this kind of problems (assuming it is well configured) and Ubuntu has "AppArmor" but I don't know if it mitigates this issue as well.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#15
post #8
post #7

Earlier quoted context omitted.

Unfortunately no major distributions ship those patches by default.

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-...

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.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#16
post #5
post #4

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

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

How do you find those addresses?

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#17
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?

Given that it looks like commits were just made 12 days ago (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) or possibly as recently as 38 hours ago (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....), perhaps only 4.4 has the fix?

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#18
post #16
post #5

Earlier quoted context omitted.

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

How do you find those addresses?

Grep for commit_creds and prepare_kernel_cred in /proc/kallsyms. The address is in the first column.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#19
post #11

Earlier quoted context omitted.

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…

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

[deleted]

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#20
post #16
post #5

Earlier quoted context omitted.

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

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;
Post reply on HN