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?
The problem with trying to sound so stupid you can't possibly be serious is that there are people who are seriously that stupid.
just kidding, of course it was the last line
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.
/whoosh, right over someone's head.
That being said, often pulseaudio and/or jackd are given realtime priviledges, so I assume people will be looking at them.
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.
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...
edit: as in, does yama.ptrace_scope prevent anyone without root and/or CAP_SYS_PTRACE from exploiting this?
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.
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.)
Oh wait, nope, not addressed:
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
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.
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.
echo 0 > /proc/sys/kernel/yama/ptrace_scope
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.
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.