Bedatec Security Advisory 200212140001
--------------------------------------
Discovered : 2002-12-08
Vendor notified : 2002-12-14 (sorry for the delay, had to check if
default is still set for RH 8.0)
Author : Andreas Beck <beckaat_private>
Application : su as contained in e.g. sh-utils-2.0.12-3.
RedHat pam packages like e.g. pam-0.75-18.7
Severity : Insecure default could allow X Session cookie stealing
from root thus gaining root priviledges for a user
already having unpriviledged acess.
Risk : Medium (root compromise, but needs interaction with root)
Vendor status : Vendor will make updated packages available shortly
Vendor statement : "Red Hat is working on updated pam_xauth packages
which adds back the missing ACL functionality.
These will be available shortly from
http://rhn.redhat.com/errata/ and via the
Red Hat Network."
Affected Versions: At least Redhat 8.0 and 7.1 are vulnerable. Supposedly
all versions in between are as well.
RedHat 7.0 and before are _NOT_ vulnerable.
CVE reference: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1160
Overview:
---------
On Redhat Linux including 8.0, PAM comes with a module pam_xauth which can
forward X MIT-Magic-Cookies to newly instantiated sessions.
While this is a nice feature and generally harmless for the case that an
unpriviledged user elevates his priviledges to root using e.g. su or the
various wrappers for some root-only programs, it poses a security risk
for root, if root uses su in order to assume the id of a less priviledged
user, e.g. for troubleshooting purposes.
Details:
--------
While checking an unrelated problem, we discovered that using su would
allow the target user to connect to the running X session owned by the
user that used su.
Quick checking
> becka@cupido$ su devel
> Password:
> [devel@cupido becka]$ xauth
> Using authority file /home/devel/.xauthupNGf8
revealed, that su seems to forward the MIT-Magic-Cookie to the target
user in a temporary .xauth-File.
> [devel@cupido devel]$ ls -l /home/devel/.xauthupNGf8
> -rw------- 1 devel devel 51 Dez 8 00:26 .xauthupNGf8
This file is owned by the target user and only readable by the target
user, as it must/should be for the method to work.
This behaviour causes a security risk when root uses su to become an
unpriviledged user for troubleshooting an account.
Possible attack scenario:
-------------------------
Write a mail to local root, stating that you have difficulties logging in,
like e.g. you get logged out after 5 seconds in which you can run programs
and everything, you just get logged out afterwards.
This should be a strange enough description, that root will probably want to
verify this behaviour.
Assuming root is running an X session on the console under his normal login
name, he will probably su to root to allow to assume the id of the
complaining user without having to supply a password by using su again.
[Depending on the method of connection, a remote X server should also do.]
The default entries in /etc/pam.d/su will cause the X session cookie to be
forwarded to first root and then the user whose "problem" is to be
investigated.
Right after sending the mail, said user places a process in memory that
will wait for the .xauth-file to appear. Only a very careful root would
check for running processes, and even then, he is not likely to shut down
something like "longrunning_calculation" that is niced up and all.
The process will grab the contents of the .xauth-File and can then
connect to the X server, as it knows the cookie. Though this is annoying
by itself (User can see what is on the root desktop, send fake events,
thus run programs as the user who started the desktop etc.), in this
scenario it is much worse, as we know that there is a terminal open
that has just su'ed to the current user, very probably from _root_.
Just send it "exit<Enter>" and then execute whatever you like.
This way you even reproduce the problem you told root about.
O.K. - he might get suspicious now, but the damage is done.
Some webpages suggest, that pam_xauth can be customized to only forward
cookies under certain conditions. However neither the manpage for su
nor the one for pam_xauth mention how to do that. Moreover the su manpage
does not state, that X forwarding is on by default.
Proof of concept/How to reproduce:
----------------------------------
Log in as an unpriviledged user ("victim"). Start up X if necessary.
Get root using su, then assume the ID of another unpriviledged user
("attacker") using su.
Log in as "attacker" remotely or from a console. Locate the -xauth file.
Give it to an arbitrary X program using the XAUTHORITY environment
variable and set display accordingly. This data can be obtained
from the shell that root started.
Program should appear on victim's X server.
Vendor Response:
----------------
2002-12-14 -> Redhat notified via EMail
2002-12-16 <- Initial response requesting extended timeline due to holidays
2002-12-16 -> Acknowledged extended timeline due to holidays
2002-12-17 <- Asked to check RH 7.0 as it seems not vulnerable due to its
ACL checking. Proposed fix to add ACL-checks back in.
2002-12-17 -> Acknowledged that RH 7.0 does not seem vulnerable judging
from its documentation. Suggested manpage fix (see below).
2003-01-12 -> Checked back with Redhat for a timeline update
2003-01-13 <- RH states fix is worked out and packages are in QA.
Suggested Feb 3rd for co-ordinated release
2003-01-13 -> Acknowledged Feb 3rd
2003-02-02 <- RH notifies of delay due to higher priority issues.
sends Vendor statement as quoted above.
As the issue is not too serious, and a workaround (Recommendation 2)
exists, I decided to publish anyway to enable security aware admins
to mitigate the problem in the meantime.
Recommendations:
----------------
To solve or mitigate the problem, choose one of:
1) Get updated vendor packages when they appear. Configure re-added ACL
functionality not to forward from root (should be default).
2) Disable pam_xauth module for su by commenting out the relevant line in
/etc/pam.d/su.
If required copy su to "sux" and make an appropriate pam.d entry that
retains the old behaviour.
3) If you already have a pam_xauth module with ACL control, change its
configuration not to forward X if su is called by root.
plus you may want to consider:
4) pam_xauth documentation should clearly state why one shouldn't forward
X11 to untrusted accounts. Something along the lines of:
"Mind that forwarding X11-cookies to other users basically allows them
to gain control over your X session. This is usually not a problem when
the target user is root, but can be one when root assumes the id of a
possibly untrusted user"
5) Be aware of the possible consequences of propagating X-Cookies to
potentially hostile environments. (ssh with -X basically opens the same
problem, though it is less readily exploitable there due to the
transparent Cookie replacement.)
Kind regards,
Andreas Beck
--
= Andreas Beck | Email : <beckaat_private> =
This archive was generated by hypermail 2b30 : Mon Feb 03 2003 - 15:58:29 PST