3 ms·

You mean su to root? The same mechanism still exists, though root already has other powers.

• masklinn 8y ago
  No, I mean su to a new shell and execute a command there rather than su -c.
  • jwilk 8y ago
    That would be weird if "su -c" was vulnerable but interactive "su" was not. The former is much easier to fix. In fact, "su" in Debian (which the subject of the submitted article), calls setsid() when you use -c, which defeats TIOCSTI.
    • masklinn 8y ago
      > That would be weird if "su -c" was vulnerable but interactive "su" was not. Not necessarily, if TIOCSTI just pushes stuff to the term input buffer, this is going to get popped on the next prompt of su, so on an interactive su it's not going to be executed under escalated privileges but is instead going to be executed as the same user that executed the hostile program, while with a non-interactive su it's going to get popped on the next prompt of the su caller and thus get escalated privileges. That's my understanding of it anyway, I could be completely off.
      • jwilk 8y ago
        I see what you mean. Yes, the exploit won't work if the payload is read by the attacker's shell, rather than the root shell. But it's easy to ensure that this won't happen. The laziest way is to kill the shell before issuing TIOCSTI ioctls. :-)