lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ