10 ms·
Analysis and Exploitation of a Linux Kernel Vulnerability
- tshtf 11y agoThe 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 11y agoTested 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 11y agoThat's not how you execute binaries, just "./cve_2016_0728 PP_KEY" is the correct syntax
- deleted 11y ago[deleted]
- LinuxBender 11y agoYes 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.
- 16 11y agoYou need to update the addresses of commit_creds() and prepare_kernel_cred() as per this: https://news.ycombinator.com/item?id=10931954 https://news.ycombinator.com/item?id=10931954
- LinuxBender 11y agoThe best I can get is an oops panic on CentOS 7. It appears smaps may be preventing the exploit from working.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- rolandr 11y agoGiven that it looks like commits were just made 12 days ago (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/security/keys?id=1d6d167c2efcfe9539d9cffb1a1be9c92e39c2c0 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.git/commit/security/keys?id=5807fcaa9bf7dd87241df739161c119cf78a6bc4 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....), perhaps only 4.4 has the fix?
- garrettr_ 11y agoThis vulnerability is a great advertisement for grsecurity/PaX, which mitigates it at the source of the issue thanks to PAX_REFCOUNT.
- corv 11y agoUnfortunately no major distributions ship those patches by default.
- eloy 11y agoWhy 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-insecurity-the-kernel-of-the-argument/ http://www.washingtonpost.com/sf/business/2015/11/05/net-of-...
- cesarb 11y agoDistributions prefer to minimize divergence from upstream, and therefore tend to avoid non-upstreamed patches.
- baghira 11y agoWhile 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.
- iheartmemcache 11y agoFYI: If you're comfortable with Gentoo, the jump to Hardened Gentoo[1] is an easy one[2] and gives TrustedBSD[3] a run for its money w/r/t out-of-the-box security. It has the SElinux MAC, role based access controlled stuff from GRsec alternatively [you can mix and match GRsec + SElinux except for RBAC and SElinux's ACL system), grsec's ASLR at runtime, modified versions of musl/uclibc, stack protection support (why anyone would write software that could possibly be EIP exploited with countless ASan damn well integrated into some compilers, I haven't a clue), and a whole host more. Some interesting academic work: http://hmarco.org/data/OnTheEffectivness-NX-SSP-RenewSSP-and-ASLR.pdf http://hmarco.org/data/OnTheEffectivness-NX-SSP-RenewSSP-and... While SSP is not enough, (use PIE too): http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.ht... A fun toy: https://github.com/JhetoX/VectorAttackScanner https://github.com/JhetoX/VectorAttackScanner [1]https://wiki.gentoo.org/wiki/Project:Hardened https://wiki.gentoo.org/wiki/Project:Hardened [2]https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Hardened_Gentoo https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Harden... [3]Granted I haven't used it in ages, it's still the benchmark I use in my mind, back when Linux 2.2 was rife with out-of-the-box ROP vulns.
- geofft 11y agoIs 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 11y agoThe 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.
- mnw21cam 11y agoWell, the exploit doesn't seem to work on my kernel 4.1.0 system, so that's good.
- 16 11y agoDid you update the addresses of commit_creds() and prepare_kernel_cred() to match your running kernel before you compiled/ran it?
- javanix 11y agoHow do you find those addresses?
- agwa 11y agoGrep for commit_creds and prepare_kernel_cred in /proc/kallsyms. The address is in the first column.
- fuuuuuuuuu 11y agohttps://gist.github.com/gcmurphy/1c91644718d28695da2d https://gist.github.com/gcmurphy/1c91644718d28695da2d ^-- this version should do that automatically
- wfn 11y agoBy 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;
- javanix 11y agoThanks, that worked.
- Maran 11y agoQuestion 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?
- tkinom 11y agoWould 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 11y agoAs 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).
- superpatosainz 11y agoYes. 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.
- rolandr 11y agoCan 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).
- NotHereNotThere 11y agoDid 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$
- baghira 11y agoIf you have SMAP, i.e. an Haswell or newer Intel CPU, you should not be vulnerable, so that could be an explanation.
- javanix 11y agoIs SMAP required for mitigation, or is SMEP enough? IIUC SMEP is on Sandy Bridge processors too.
- baghira 11y agoAccording 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.
- cmurf 11y agoI have Sandy Bridge, i7-2820QM. The exploit code has been running for nearly an hour, still "Increfing..." EDIT: [chris@f23m cve20160728]$ ./cve_2016_0728 PP_KEY uid=1000, euid=1000 Increfing... finished increfing forking... finished forking caling revoke... uid=1000, euid=1000 sh-4.3$
- benmmurphy 11y agoSMEP would stop this particular exploit because it returns into usermode but SMEP is trivial to bypass on linux if there is no KASLR or other mitigation (apparently there are compiler plugins that remove popular stack pivot gadgets).
- 11y ago
- cmurf 11y agoFedora is currently building a 4.3.3-X for F22 and F23 that includes a fix.
- pearjuice 11y agoTo 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!"
- oldmanjay 11y agoi guess learning that unqualified opinions don't really convey useful information is a valuable lesson no matter how you learn it.
- redahs 11y agoOpen 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 11y agoWhat 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 11y agoHas the demo code actually worked for anyone?