Re: TTY handling when executing code in lower-privileged context (su, virt containers)

[Georgi Guninski <guninski () guninski com>]

I suspect X makes this much worse.

On Sat, Nov 10, 2012 at 04:45:44PM +0000, halfdog wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello List,
>
> To all those, who already read the discussion on oss-security, please
> excuse the cross-posting. Since this problem is more a
> tool-documentation (su, vserver) and admin good-practice issue, this
> post should make all those aware, who not already knew.
>
>
>
>
> During programming experiments I found some class of vulnerabilities
> [1], that seem to be rediscovered again from time to time, but since
> they can also be attributed to admin error and attack value is
> questionable, there is no fix yet and might never be.
>
> The basic idea is, that a program started from interactive shell can
> access the TTY and also inject input data using TIOCSTI ioctl. This is
> not an issue when the program is running in the same execution
> context, but may allow privilege escalation when the program switches
> to another context without closing the TTY file descriptors. In that
> case a malicious program running in the lower privileged context can
> inject commands to be executed by the interactive shell running with
> higher privileges.
>
> Test were made using 'su' from root to 'test' user under ubuntu, which
> is vulnerable to that kind of attack.
>
> Also entering a virtualization container is a problematic context
> switch. 'vserver enter' [2] was found to be vulnerable for command
> execution outside container while 'lxc-console' was not.
>
>
> At least with 'su', this vulnerability is known for years. In my
> opinion this is because the fix is not quite trivial and the proposed
> attack method requires root running interactive shell switching to a
> problematic user account (local access, user interaction). So the CVSS
> for this would be quite low.
>
>
> I have proposed following "fix" for this problem: Modification of
> man-page of su making this a known problem or feature, not a bug.
>
> "Using su to execute commands as an untrusted user from an interactive
> shell may allow the untrusted user to escalate privileges to the user
> running the shell."
>
>
> If context-switch is needed, following workarounds are available:
>
> * When no interactive shell is needed in lower-privileged context, su
> et al. can be run with stdin, stdout, stderr redirection, not passing
> a tty-fd to the other context
>
> * The tool screen from a package with the same name [3] creates a pty
> for each process. Calling screen su [user] does not pass the tty of
> the privileged user directly to the lower-privileged context.
>
>
> For the later variant, I would be interested, if there are any known
> ways to bypass that. I am not sure if screen was really designed for
> security-critical application.
>
> hd
>
> [1] http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/
> [2] http://linux-vserver.org/
> [3] http://savannah.gnu.org/projects/screen
>
> - -- 
> http://www.halfdog.net/
> PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAlCegs8ACgkQxFmThv7tq+7BWgCeMw8OiqQED66QCwt4iYFGmIEu
> c2MAn3OIxTJqbMjQmaEoRZiKzMmY44X8
> =LZmk
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/