4 ms·

This explains the problem a little clearer I think: https://bugzilla.redhat.com/show_bug.cgi?id=173008 https://bugzilla.redhat.com/show_bug.cgi?id=173008

masklinn 8y ago
So if I understand correctly, the issue is that when su-ing to more restricted privileges a hostile program (immediately executed via -c) can use TIOCSTI to inject commands which will escape su and execute as the more privileged user? Is that also an issue using `su; ./hostile; exit`?
- tedunangst 8y ago
  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. :-)
- JdeBP 8y ago
  No, but it is with ( sleep 10 ; hostile ) & su The problem exists when an process with superuser privileges is running a program that reads command input interactively from the terminal at the same time that an unprivileged process has an unrevoked open file descriptor to the same terminal device.

masklinn 8y ago

So if I understand correctly, the issue is that when su-ing to more restricted privileges a hostile program (immediately executed via -c) can use TIOCSTI to inject commands which will escape su and execute as the more privileged user? Is that also an issue using `su; ./hostile; exit`?

tedunangst 8y ago
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. :-)
JdeBP 8y ago
No, but it is with ( sleep 10 ; hostile ) & su The problem exists when an process with superuser privileges is running a program that reads command input interactively from the terminal at the same time that an unprivileged process has an unrevoked open file descriptor to the same terminal device.