Hacker News Reader

Comment by bcoates | Hacker News Reader

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

It's on by default on Ubuntu.

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

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

Reply on news.ycombinator.com