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

61–70 of 70 posts

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#61

Post by redahs »

pearjuice wrote: post #54

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

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.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#62

Post by chatmasta »

redahs wrote: post #61
pearjuice wrote: post #54

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

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

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.

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#63

Post by cyphar »

pearjuice wrote: post #54

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

Free software allows users to get access to fixes for systems not supported by vendors. Saying "free software" is more secure is not correct (just look at libpurple, a free software library riddled with bugs). What is correct is that you have a much better shot at white hats and security researchers finding bugs in free software, and the fixes for those bugs being freely available.

Black hats (trust me, I've known a few) will gladly attack proprietary software (usually with more glee, because there's far less review of proprietary software in general). Using proprietary software doesn't save you from black hats. But it does give you more chances of white hats finding the bugs sooner.

Security isn't a binary state, it's a lifestyle. All code has bugs, and almost all bugs can be security bugs. Taking steps to add more layers to your security is what you should be doing, not arguing that "because the software is free someone found it!".

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#64

Post by 5ilv3r »

chatmasta wrote: post #62
redahs wrote: post #61

Earlier quoted context omitted.

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

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.

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

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#67

Post by vnik »

thefreeman wrote: post #37
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)

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

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#68

Post by [deleted] »

vnik wrote: post #67
thefreeman wrote: post #37

Earlier quoted context omitted.

Did you update the addresses of the kernel functions? #define COMMIT_CREDS_ADDR (0xffffffff81094250) #define PREPARE_KERNEL_CREDS_ADDR (0xffffffff81094550)

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

[deleted]

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#69

Post by Maran »

baghira wrote: post #53
Maran wrote: post #44

Earlier quoted context omitted.

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

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

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

Re: Analysis and Exploitation of a Linux Kernel Vulnerability

#70

Post by LinuxBender »

16 wrote: post #32
LinuxBender wrote: post #9

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…

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

The best I can get is an oops panic on CentOS 7.

It appears smaps may be preventing the exploit from working.

Post reply on HN