7 ms·

> This exit back to root is not a security hole Wait... Doing just "su bob" is vulnerable to a known decades old exploit. You should do either "exec su bob" o

> This exit back to root is not a security hole Wait... Doing just "su bob" is vulnerable to a known decades old exploit. You should do either "exec su bob" or "su -P bob" or you just gave bob root rights on every Linux kernel older than 6.2 (and I think on 6.2 and more recent the default is still insecure?). It's explained here with a simple PoC exploit (I tried the exploit and it works/worked) and it's been frontpage on HN in the past I think: https://www.errno.fr/TTYPushback.html https://www.errno.fr/TTYPushback.html

hulitu 3y ago
> Consider this python sample and assume it’s automatically being run at logon from the .bashrc of a technical account, such as postgres, to which the root user changes by typing su - postgres From su man page: "su is mostly designed for unprivileged users, the recommended solution for privileged users (e.g., scripts executed by root) is to use non-set-user-ID command runuser(1) that does not require authentication and provides separate PAM configuration. If the PAM session is not required at all then the recommended solution is to use command setpriv(1)."
- erik_seaberg 3y ago
  Why does PAM have sessions? I thought it was a layer of indirection over whether you’re using a password file or NIS or LDAP to verify passwords.
  - yrro 3y ago
    PAM provides authentication, authorization, session management and password changing.
kazinator 3y ago
I think that with that ioctl in place, once root hands the TTY file descriptor to processes in the bob security context, it can no longer trust that TTY object to be secure. Doing an "exec su ..." doesn't necessarily fix it, unless that has the effect of destroying the session (logging out). If root keeps using that TTY and trusting its input, it's a problem. Say you want to fix the problem, while continuing to support that dubious ioctl. What you need is the ability for the TTY driver to send a SIGKILL to every user bob process that has an open file descriptor to that TTY. After killing all those processes, then restore the original TTY settings before the su command was run using tcsetattr with TCSAFLUSH to throw away any pushed input. Even then, there could be exploits that use weaknesses in the terminal emulator to reflect input. Also, social engineering hacks. The same human that operated the root shell is su'd into bob, and malicious software installed by bob can fool that human. For instance, by simulating a system login prompt.

hulitu 3y ago

> Consider this python sample and assume it’s automatically being run at logon from the .bashrc of a technical account, such as postgres, to which the root user changes by typing su - postgres From su man page: "su is mostly designed for unprivileged users, the recommended solution for privileged users (e.g., scripts executed by root) is to use non-set-user-ID command runuser(1) that does not require authentication and provides separate PAM configuration. If the PAM session is not required at all then the recommended solution is to use command setpriv(1)."

erik_seaberg 3y ago
Why does PAM have sessions? I thought it was a layer of indirection over whether you’re using a password file or NIS or LDAP to verify passwords.
- yrro 3y ago
  PAM provides authentication, authorization, session management and password changing.

kazinator 3y ago

I think that with that ioctl in place, once root hands the TTY file descriptor to processes in the bob security context, it can no longer trust that TTY object to be secure. Doing an "exec su ..." doesn't necessarily fix it, unless that has the effect of destroying the session (logging out). If root keeps using that TTY and trusting its input, it's a problem. Say you want to fix the problem, while continuing to support that dubious ioctl. What you need is the ability for the TTY driver to send a SIGKILL to every user bob process that has an open file descriptor to that TTY. After killing all those processes, then restore the original TTY settings before the su command was run using tcsetattr with TCSAFLUSH to throw away any pushed input. Even then, there could be exploits that use weaknesses in the terminal emulator to reflect input. Also, social engineering hacks. The same human that operated the root shell is su'd into bob, and malicious software installed by bob can fool that human. For instance, by simulating a system login prompt.