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