11 ms·

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 with

by bcoates 14y ago

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?

tedunangst 14y ago
No, you can exploit this by ptracing your child. It's not targeting a special process. (Does anybody use yama.ptrace_scope?)
- bcoates 14y ago
  It's on by default on Ubuntu.
- sounds 14y ago
  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.)
px43 14y ago
No, the PoC forks and ptraces the child, which is allowed in even the strictest yama settings.
ajross 14y ago
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.
- tedunangst 14y ago
  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.
  - ajross 14y ago
    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.
    - lawnchair_larry 14y ago
      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.
      - ajross 14y ago
        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.
        tedunangst 14y ago
        Strong disagree. "This race condition is way too small for anybody to exploit" is not the good kind of speculation.
        lawnchair_larry 14y ago
        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.

by bcoates 14y ago

tedunangst 14y ago

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

bcoates 14y ago
It's on by default on Ubuntu.
sounds 14y ago
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.)

px43 14y ago

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

ajross 14y ago

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.

tedunangst 14y ago
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.
- ajross 14y ago
  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.
  - lawnchair_larry 14y ago
    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.
    - ajross 14y ago
      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.
      - tedunangst 14y ago
        Strong disagree. "This race condition is way too small for anybody to exploit" is not the good kind of speculation.
      - lawnchair_larry 14y ago
        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.