Date: Mon, 12 Nov 2012 09:12:54 +0200
From: Georgi Guninski <guninski@...inski.com>
To: halfdog <me@...fdog.net>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: TTY handling when executing code in
 lower-privileged context (su, virt containers)

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/

Powered by blists - more mailing lists