5 ms·
CVE-2013-0871: Linux arbitrary kernel-mode code execution
- swanson 14y agoHah! Where are the Linux neckbeards now? Another day, another Linux vulnerability it seems like. Honestly, how much longer are we going to build on this house of shaky cards? Did they really think that letting a race condition happen on PTRACE_SETREGS was a good idea? Just for "elegance sake"? Come on. Everyone could tell that none of ptrace/jctl callers actually want to wakeup a TASK_WAKEKILL task, but they can't specify the necessary mask. My startup still runs Cobol on Cogs in DOS (and we serve over 9000 requests per second on a single DigitalOcean $5 box!).
- StefanKarpinski 14y agonot sure if trolling or actually runs DOS
- nilved 14y agoPretty obviously joking.
- derleth 14y ago> Pretty obviously joking. The problem with trying to sound so stupid you can't possibly be serious is that there are people who are seriously that stupid.
- eclipxe 14y agoPoe's Law [1] [1] http://tvtropes.org/pmwiki/pmwiki.php/Main/PoesLaw http://tvtropes.org/pmwiki/pmwiki.php/Main/PoesLaw
- jpdoctor 14y agoGreat list on that site, but I'm surprised they missed one of the granddaddies of such reports: http://en.wikipedia.org/wiki/Spaghetti_tree_hoax http://en.wikipedia.org/wiki/Spaghetti_tree_hoax
- raverbashing 14y agoYeah, for me what gave away is the 9000 requests on Digital Ocean, because obviously you can do 10x that just kidding, of course it was the last line
- randomdata 14y agoThere was a, presumably serious, post made here about Rails that was almost word-for-word, save the differing technical terms. The post here was obviously making fun of that other post, but I guess that would be lost without the prior context.
- sp332 14y agoCOBOL ON COGS is a joke, plus I'm pretty sure a true user would get the spelling and capitalization right :) http://www.coboloncogs.org/INDEX.HTM http://www.coboloncogs.org/INDEX.HTM
- kintamanimatt 14y ago"(c) <DATE OVERFLOW>" Oh dear!
- frozenport 14y agokeeps his machine cool by using only 1 of 32 cores on his AMD bulldozer dual socket server board.
- hysterix 14y agoNot trolling, he's just a complete moron who got butthurt when people called his precious ruby as being a pile of insecure shit.
- pyre 14y ago| Hah! Where are the Linux neckbeards now? ubi sunt[1]? [1] http://en.wikipedia.org/wiki/Ubi_sunt http://en.wikipedia.org/wiki/Ubi_sunt
- ubernostrum 14y agoI'll believe it when Netcraft confirms it.
- deleted 14y ago[deleted]
- homosaur 14y ago<blink>As long as your site still works in Netscape Navigator 2.0, I don't give a crap what you use on the backend.</blink>
- riffraff 14y agoplease have all my upvotes
- anonymous 14y agoGood post, but I'm afraid high sarcasm is lost on this crowd.
- hysterix 14y agoI love how ruby fanboy/fanaticism is not downvoted. Just look at your about page. "ruby by day, rails by night" No, no bias to be seen here, move along! You are a complete moron. This isn't even comparable with those ruby vulns, they were remote, this isn't. It is pretty obvious ruby isn't a fully mature platform to develop on, there has been dozens of posts illustrating that. Linux is a stable operating system that is fully mature and capable of running enterprise level software. The fact I need to point this out to you says you are either a troll, or living in denial, either of which are hilarious. The level of fanaticism towards ruby on this site is unbelievable. Ruby is an immature platform, I'm sorry if this fact makes your stomach turn circles and keeps you up at night. As illustrated here, http://news.ycombinator.com/item?id=5230358 http://news.ycombinator.com/item?id=5230358 "But even with access, this is awfully hard to exploit. You need a precisely timed kill, followed by a precisely timed preemption. That's really (really) hard on a multi-cpu machine" This exploit isn't even in the same league as the remote vulns for ruby. There was a working exploit within a day! The fact you'd even make comparison of the two shows how ignorant you really are. Posts like this make me laugh because I'm sure you will be jumping on the next band wagon whenever the next popular thing comes riding through town, and will probably be vehemently defending that when it has vulnerabilities.
- apawloski 14y agoI'm 100% sure he was being facetious.
- SkyMarshal 14y ago>Cobol on Cogs in DOS /whoosh, right over someone's head.
- adamnemecek 14y agoI really like this recent trend where stuff like this is getting posted and (more importantly) getting upvoted.
- jewel 14y agoFor me a lot of it feels like noise. Back when I was in charge of security at a payment processor I was subscribed to all the relevant mailing lists (as required by the PCI DSS). Now that I'm working with something less valuable I just rely on apticron + nullmailer to notify me of important security updates to system packages, and the rails security mailing list for rails. It'd be wonderful if something similar were implemented for rubygems. If security updates were marked in some way, a cron job could scan my Gemfiles periodically and then check each gem to see if any security updates have been released.
- adamnemecek 14y agoI know where you are coming from but I feel like the exploits that do make it to the front page are pretty saucy.
- ushi 14y agohttps://github.com/postmodern/bundler-audit https://github.com/postmodern/bundler-audit
- akkartik 14y agoI upvote pretty much anything that shows code.
- bcoates 14y agoA lot of uses of ptrace require root on many distros, does this vulnerability work when that's enabled? edit: as in, does yama.ptrace_scope prevent anyone without root and/or CAP_SYS_PTRACE from exploiting this?
- tedunangst 14y agoNo, you can exploit this by ptracing your child. It's not targeting a special process. (Does anybody use yama.ptrace_scope?)
- bcoates 14y agoIt's on by default on Ubuntu.
- sounds 14y agoHas anyone estimated the probability of success? What is the average number of attempts to get the scheduling conditions to happen? Assume the user can get access to a CPU core that is otherwise idle. sched_setaffinity(2) will succeed when run by the process to set its own affinity to a specific core, so the attacker can locate the processes on a chosen core. (The attacker could spend a few milliseconds first to find an idle core.)
- px43 14y agoNo, the PoC forks and ptraces the child, which is allowed in even the strictest yama settings.
- ajross 14y agoYes, ptrace can be globally disabled by a file in /proc somewhere, I believe. I forget the details. But even with access, this is awfully hard to exploit. You need a precisely timed kill, followed by a precisely timed preemption. That's really (really) hard on a multi-cpu machine, and it's worth pointing out that the exerciser case in the bug has to patch in a sleep for the exploit to work. It's not clear if they have a real world exploit running, though of course the race is real.
- csense 14y agoCan anyone explain what access is necessary to use this attack? I'm guessing anyone with shell access (can run arbitrary shell commands from an unprivileged account) will be able to use this to get root. But that's just a guess; kernel experts are welcome to weigh in.
- astrodust 14y agoAny application that has a vulnerability can run arbitrary code, such as an insufficiently patched WordPress, could enable privilege escalation using this flaw.
- sounds 14y agoThat's a bit of an exaggeration, because this requires a precise race condition. The race condition is very possible but fairly unlikely unless you apply the Proof-of-Concept patch to make a huge gaping delay in the kernel where the exploit can run. WordPress probably has unpatched vulnerabilities, but it would take many thousands of attempts to exploit this hole.
- StavrosK 14y agoDoesn't that take around a second?
- thefreeman 14y agoThere isn't even a working exploit yet. As someone else mentioned, they include a kernel patch with their proof of concept to allow you to reproduce it.
- thirsteh 14y agoA PoC and an exploit are equivalent. Attackers have saved the time trying to figure out how to leverage it.
- deleted 14y ago
- ineedtosleep 14y agoIs this a vulnerability across all Linux versions or some of the more recent versions (e.g. 3.7.x)?
- ck2 14y agoDid centos 2.6.32-279.22.1.el6 address this on Feb 6th or is this something new? Oh wait, nope, not addressed: https://rhn.redhat.com/errata/RHSA-2013-0223.html https://rhn.redhat.com/errata/RHSA-2013-0223.html I thought the responsible thing to do was not announce it until there was some headstart time? Strangely it's not in the redhat db yet at all https://access.redhat.com/security/cve/CVE-2013-0871 https://access.redhat.com/security/cve/CVE-2013-0871
- rbanffy 14y ago> I thought the responsible thing to do was not announce it until there was some headstart time? I may be wrong, but from the report, it seems to be a somewhat difficult local exploit that can lead to privilege escalation. While it's serious in that it allows arbitrary code to run in kernel space, it also seems to pose a low risk due to how hard it is to put all the required pieces in place. Also, there are already corrections available.
- X-Istence 14y agoThere is responsible disclosure, full disclosure and no disclosure. I'll take the first two over the last any day of the week. It may be responsible, but there certainly isn't a requirement to do responsible disclosure.
- batgaijin 14y agoSELinux wouldn't stop this, right?
- brokenparser 14y agoI think you can use SELinux to prevent this attack. See http://fedoraproject.org/wiki/Features/SELinuxDenyPtrace http://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
- onedognight 14y agoFirst, this is local exploit. Second, most distributions do not allow access to realtime scheduling by regular users. In particular, a simple for(;;); at the highest SCHED_FIFO priority will lock the box. You can check /etc/security/limits.conf to see which users / groups are allowed a higher than normal rtprio. That being said, often pulseaudio and/or jackd are given realtime priviledges, so I assume people will be looking at them.
- ck2 14y agoSo correct me if I am wrong, to disable ptrace? echo 0 > /proc/sys/kernel/yama/ptrace_scope Grsecurity kernels also seem to have /proc/sys/kernel/grsecurity.harden_ptrace
- andri 14y agoAccording to https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening... setting it to zero would actually restore the more permissive behavior. But, like someone here mentioned, a value of 1 would still allow to ptrace your own process children.
- FooBarWidget 14y agoThere have been multiple local kernel exploits in the past few years. For somebody who doesn't constantly watch seclists.org or similar security sites, how do I find out whether my kernel is vulnerable to any known exploit? Is there a tool that can help me with checking? Is there a notification tool?
- 0x0 14y agoYour distro probably has a mailing list for announcing updates. For debian, you should subscribe to http://lists.debian.org/debian-security-announce/ http://lists.debian.org/debian-security-announce/ - and you'll get an email as soon as updates are published. These are also published at http://www.debian.org/security/ http://www.debian.org/security/ You can also follow security bugs closely on the security tracker. For example, this vulnerability is classified here: https://security-tracker.debian.org/tracker/CVE-2013-0871 https://security-tracker.debian.org/tracker/CVE-2013-0871 and the full list of bugs affecting the stable kernel is here: https://security-tracker.debian.org/tracker/source-package/linux-2.6 https://security-tracker.debian.org/tracker/source-package/l...
- Rovanion 14y agoI just set my distro to automatically install security fixes from my distributor. Only requires a reboot for kernel updates and it is a no effort solution to the problem.