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