Message-ID: <509E84B8.8050309@halfdog.net>
Date: Sat, 10 Nov 2012 16:45:44 +0000
From: halfdog <me@...fdog.net>
To: full-disclosure@...ts.grok.org.uk
Subject: TTY handling when executing code in
 lower-privileged context (su, virt containers)

-----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/

Powered by blists - more mailing lists