CVE-2013-0871: Linux arbitrary kernel-mode code execution | Hacker News Reader

CVE-2013-0871: Linux arbitrary kernel-mode code execution

seclists.org

134 pointsfriism58 comments

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

  | Hah! Where are the Linux neckbeards now?

ubi sunt[1]?

[1] http://en.wikipedia.org/wiki/Ubi_sunt

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

not sure if trolling or actually runs DOS

COBOL 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

"(c) <DATE OVERFLOW>"

Oh dear!

keeps his machine cool by using only 1 of 32 cores on his AMD bulldozer dual socket server board.

Pretty obviously joking.

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

Poe's Law [1]

[1] http://tvtropes.org/pmwiki/pmwiki.php/Main/PoesLaw

Great 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

Yeah, 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

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

Not trolling, he's just a complete moron who got butthurt when people called his precious ruby as being a pile of insecure shit.

I'll believe it when Netcraft confirms it.

Good post, but I'm afraid high sarcasm is lost on this crowd.

please have all my upvotes

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

I'm 100% sure he was being facetious.

>Cobol on Cogs in DOS

/whoosh, right over someone's head.

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

RT privilege is not a prerequisite to this exploit, it only makes it 'easier'.

As a matter of fact, I also just realized that it may be possible that nice-ing the 'victim' process down to -20 may also make it easier, and is a non-privileged operation almost everywhere.

I really like this recent trend where stuff like this is getting posted and (more importantly) getting upvoted.

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

I know where you are coming from but I feel like the exploits that do make it to the front page are pretty saucy.

https://github.com/postmodern/bundler-audit

I upvote pretty much anything that shows code.

There 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?

Your distro probably has a mailing list for announcing updates.

For debian, you should subscribe to 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/

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 and the full list of bugs affecting the stable kernel is here: https://security-tracker.debian.org/tracker/source-package/l...

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

A 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?

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

There's no penalty for losing the race and trying again. It's not like it's making noise and filling up logs or anything like that. Maybe somebody would notice the CPU spinning if you're hammering it, but that's avoidable.

That's true, of course. But time is still a finite resource and it's possible to have a theoretical race with a window so narrow that it can't actually be exploited in feasible time. The fact that the proof of concept had to artificially open the window is evidence that this might be such a situation. It's still a hole; it just might not be big enough to push a hack through.

You're speculating, but you're wrong, FYI. You're also wrong that the PoC requires a patch to work. That's just to make the window gaping and foolproof, basically.

Better to speculate and be wrong than assert without evidence. How long does the exploit take to run successfully on your test system? Did you even build it? I did, and it doesn't. Go away.

Strong disagree. "This race condition is way too small for anybody to exploit" is not the good kind of speculation.

You asserted without evidence. I've successfully run it repeatedly. You don't have to believe me, but in dismissing the impact, you're making a common error. Probability of the event occurring naturally has very little to do with risk, particularly when there are no consequences for failing.

No, you can exploit this by ptracing your child. It's not targeting a special process. (Does anybody use yama.ptrace_scope?)

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

It's on by default on Ubuntu.

No, the PoC forks and ptraces the child, which is allowed in even the strictest yama settings.

Did 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

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

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

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

Is this a vulnerability across all Linux versions or some of the more recent versions (e.g. 3.7.x)?

So 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

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

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

Any application that has a vulnerability can run arbitrary code, such as an insufficiently patched WordPress, could enable privilege escalation using this flaw.

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

Doesn't that take around a second?

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

A PoC and an exploit are equivalent. Attackers have saved the time trying to figure out how to leverage it.

well, the exploit is linked ;-)

SELinux wouldn't stop this, right?

I think you can use SELinux to prevent this attack. See http://fedoraproject.org/wiki/Features/SELinuxDenyPtrace

Reply on news.ycombinator.com