Bug 57238 (CVE-2002-1160)

<!-- SBZ_reproduce  -->
create a test user.

run: "su - user" and try to start a graphical application.

pam_xauth has a very bad reputation and big problems in the past. 

I could understand if you want "su -" to have these semantics (easy starting of
YaST), but switching from a non-root user to another non-root user should never
give the target user X access _by default_.
Besides that, what is the point of running a program as another user if you give
this user permission to fsck with your X11 session by default?

We had problems with "maybe insecure, but convenient" programs in the past and
we have enough security bugs as is, no need to add additional risks.

Thorsten:  I would be shocked to find any process or application which is
explicitly used for priviledge escalation or changes that has never had security
holes found against it.  Here's the hole:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1160
The basic idea that root becomes a normal user through su and forwards root's X
credentials.  The user spots the temporary XAuthority file and uses it to gain
access to root's X session.

The is has been fixed by providing fine grained access control and disallowing
root -> user X cookies by default.  Note that I was unable to find any previous
problems with this 614 line pam module and this hole was reported in 2002. 
(Although not widely patched until 2003.)

Carl-Daniel:  "su -" will also work with this PAM module, and that is most
likely the common case.  Other cases:

su'ing to another user so they can run an application without having to start a
second X session or logging out.  

su'ing to another user to run multiple copies of an application that only allows
one copy to be run at a time.

I believe that it's more common to run as another user and expect that the X
settings will work, but I'm thinking of desktop use for the most part.

Also, the lack of this setting is that I often (and other users seem to) run
"xhost +" frequently.  This leads to much worse security problems.

About comment#5: Use "sux - otheruser". It will save you seven keystrokes
compared to "su - otheruser" and "xhost +" and it is more secure. Giving su the
functionality of sux would add potential security problems while saving you
exactly one keystroke.
Benjamin: Your comments in this bug amount to 2708 chars, so to reach a
break-even you have to switch users with your suggested method 2708 times. That
will take quite some time.

However, your point with frequent usage of "xhost +" is valid. We should
probably add a warning message to it. Something like "xhost + is insecure.
Please consider using sux or ssh -X instead" would make sense.

to comment #5: Please don't "frequently" run "xhost +", particularly not if
you already know that it is to be considered insecure.

A simple reason for not transporting an X11 authentification cookie to another
user in the system is that you can't turn it off.

You're logged in as xkahn, you su to root, then you su to some other unprivileged
user. And each time you use su again afterwards you end up typing a password
into an X-server that you can't tell who's listening on it. That may be 
convenient, yes, but mostly for an attacker.

Does that ease the discussion?

Thanks,
Roman.

Roman,

   Actually, the example you gave would not get X privs.  (Su'ing from root to
another user doesn't forward the X privs unless you have turned it on for that
user combination explicitly.)  

However, you make a good point:  There should be a way to make "su" NOT forward
X privs if it is set up to do it by default on a invocation by invocation basis.
 (Obviously the access control stuff works, but a command line flag would allow
snap judgements better.)

Carl-Daniel: Documentation whenever su is invoked sounds like an interesting
idea.  Maybe that really is the answer?

Some conclusion on how we should proceed? 

Let me summarize the choices and the tradeoffs.

1) Leave everything as it is.
2) Turn on pam_xauth, but add a flag to "su" to actually use it.
3) Turn on pam_xauth, but add a flag to "su" to turn it off again for a single
invocation.
4) Print a message when using "su" that they might want to try "sux" instead.

These are the use cases I can think of:

a) Becoming root to run a (possibly) graphical application. [ user -> root ]
b) Switching to another account which is also yours.  (Test Account) [ user ->
trusted user ]
c) Switching from root to a user account for testing. (Yes, this sounds like a
bad idea...  Root with X privs, but it can happen and should not cause problems)
[ root -> untrusted user ]
d) Allowing another user to log in through your shell into their own. [ user ->
untrusted user ]

Obviously these can be chained, but I'm ignoring that because it should not
significantly effect the security implications.

Case 1:
a, b, d)
User runs "su" and becomes root.  There is no X access at all.  The root user
can not access the user's X server at all.  The user must use "xhost +" and set
the DISPLAY environment variable to run graphical apps.

Result: 
If the user isn't running an X application, the user is fully protected and
their X session is not compromised in the least.  If the user is running an X
application, their X session has the potential to be easily compromised by any
user on the network.

c) If the application the root user runs as the untrusted user is not an X
application, everything works great.  However, if root runs xhost + to grant
access to graphical applications, the root account and the X server can both be
compromised by any user on the network.

OR

User runs "sux" and becomes root.  The root account is granted access to the
user's X session completely, although other users logged into root will have to
set the display appropriately to do anything.  This is probably okay since "if
you can't trust root, you probably have other problems"

a) Root is given access to the user's X session on all logins simply by setting
the DISPLAY variable correctly until the user is logged out.

b) No security problems since you control both accounts.

c) The untrusted user is given access to root's X privs when they are logged in
at the same time and set the DISPLAY variable correctly until you log out..

d) The untrusted user is given access to your X privs when they are logged in at
the same time and set the DISPLAY variable correctly until you log out.  But you
probably have bigger problems since they have access to your session anyway.

Case 2) This is probably the same as 1 (in the average case) and 3 (when the
switch is enabled)

Case 3) 
a) A new Xauthority file is created which is special to this "su" invocation. 
Root can set their environment variable and their XAUTHORITY variable to the
temporary .Xauthority file which is created.  When you exit the "su" session,
root loses rights.

b) No security problem since you control both accounts.

c) The X priviledges are not transferred to the untrusted user unless the root
account explicitly sets it up.  No security problem.

d) Similar to a, but you have other problems already.

Case 4) Similar to Case 1, but users are more likely to discover the "sux"
command and use it instead of using su/xhost.


-------------------


I believe the most secure setup is Case 3, but Case 4 might be a viable option.

pam_xauth uses temporary X privs and creates unique .Xauthority file names to
keep accidental granting of privs to untrusted users.  It automatically does not
transfers X privs when going from root -> user.

IMO the best choice would be
4) Print a message when using "su" that they might want to try "sux" instead.

and print a warning (maybe the same message as above) when anybody uses "xhost +"

note that sux doesn't remove privs until you log out of X.  I think my writing
was unclear above.

IMHO this is a bug in sux. sux should remove privs after you log out of your sux
session. See bug 59605 for details.

You mean three bugs:

(1) sux isn't a standard command in UNIX and thus is hard to find for both
experts and newbies. (who might naively expect this to all just /work/) 
(2) sux doesn't remove privs after you log out of the "su" session.
(3) sux adds the privs to the new user's standard .Xauthority file making it
much easier to capture a session.  (Although admittedly, not THAT much easier.)

(And (4) -- sux looks and sounds like the english word "sucks" asnd makes
everyone who hears it giggle and laugh.)

added su maintainer because it might affect him... 

Created attachment 23708 [details]
This patch adds the -x or --no-x flags to su

sux bug filed as: http://bugzilla.suse.de/show_bug.cgi?id=45672

sux bug filed as: http://bugzilla.suse.de/show_bug.cgi?id=45673

Filed a bug against su: http://bugzilla.suse.de/show_bug.cgi?id=45674

The "sux" name problem has already been filed:
http://bugzilla.suse.de/show_bug.cgi?id=34834

Also, I just found this bug:
Bugzilla Bug 59605 - sux does not remove X privs from target user after
termination of target session

which has been closed RESOLVED WONTFIX.

Created attachment 23713 [details]
REAL patch to add the -x switch to su

*sigh*	The last patch was a patch against a previous version of my patch. 
Silly RPM screw up on my part.	This is the REAL patch.  Sorry for the
confusion.

Do you think this will work? The Xauthority file is usually mode 600, so  
simply passing on the DISPLAY and XAUTHORITY variables to the destination  
account will only work if you su to root, and Xauthority file isn't on  
an NFS mounted file system with root_squash on.  
  
pam_xauth looks reasonably sane except that you want to rely on .xauth/export  
instead of .xauth/import (because the originating user bestows privileges  
on a potentially untrusted destination user).  

This is the reason why the script sux was written in such a way
to include the magic cookie into the new users .Xauthority file.
And also why sux does a `cat ~/.Xauthority > /dev/null' as old
user to be able to read the magic cookie out from the old users
~/.Xauthority with an open file descriptor as new user.

Olaf:  It took me a while today to figure out what you were talking about with
regards to my patch.  I believe you mean that my patch, when not used with
pam_xauth, has a useless option since the user will see a permission denied
error when they try a graphical application.  This is as designed, yes. 
(Permission denied seems like the real error to me, instead of "can't find your
X session.)  On the other hand, this patch is designed to be used with pam_xauth
normally.  I am recommending that pam_xauth be enabled and this patch to su be
applied.

Also, yes, you are correct about the import/export stuff.  export is probably
the better option, but it is nice they allow you to do both.

werner:  I believe that to be a security hole in sux.

Ok to summarize it again: 
- drop sux and 
- switch to pam_xauth + your patch for su 

Three questions:

  * User alice does a su to root and works several hours.
    User bob does a su to root.  How does su/pam protect the
    magic cookies of alice during their session to not be
    obtained by bob?

  * User bob does a su to root and then a simple `su - alice'
    ... How do su/pam protect the magic cookies of alice to not
    be obtained by bob?

  * Does su/pam also work for ssh connections? That means
    that the su should also work on a remote system with
    the display routed by the ssh tunnle to the local display.

... the first two points are the same risk as with sux ;^)

Werner:  good questions.

1) I assume in this scenario that Alice and Bob have both su'd to root at the
same time because pam_xauth removes X permissions at exit, so Alice's perms
wouldn't still exist if she had exited the session.

I also assume that Alice has an X session running and is either local to the box
or is remote (ssh'd with X perms transferred.)

su/pam does not by default give Bob access to Alice's session.  They both have
different Xauthority files and their DISPLAY environment variables are
different.  Even if Bob set his DISPLAY to match Alice's he would not gain
access to Alice's session.  However....

While Alice is still logged in, Bob needs to know two pieces of information to
steal Alice's session:  Alice's DISPLAY setting and her XAUTHORITY setting. 
Since they are both the same user (root in this case) Bob can simply cat
/proc/<process id of any program Alice is running>/environ and locate these two
values.

2) When Bob is not acting with malicious intent, Bob does not gain access to
Alice's session.  His DISPLAY and XAUTHORITY environment is actually cleared in
this case. (to protect Bob from Alice)

If Bob wants to steal Alice's session, Bob doesn't even need to su to Alice to
steal her X permissions.  He can simply read Alice's .Xauthority file directly
and steal her X perms.  (And he'll need Alice's DISPLAY settings as well, but he
can perform the same trick as above.)

3) Yes.  This works.

Werner, if you are on a system where you do not trust root, you have problems
already.  It probably isn't possible to protect users from a root user who is
malicious EVER.  That's why rooted boxes always need to be completely
re-installed.   This isn't a problem with either sux or pam_xauth, but is a flaw
in UNIX's (and by extension) Linux's security model.  If you are interested in
solving this problem, you should be looking at SELinux.

Yep this is exactly what I know ;^)
... the same holds true for sux: If you can not trust the people
with root access you always loose.  There is no way to hinder
root to get the magic cookies of other users.

Thomas:  Yes.  That is my recommendation.

Werner:  I think we're going around in circles and I'm losing interest.  There
are 3 current problems my recommendation is intended to solve.

1) pam_xauth is community maintained and solves some security issues which are
in the current version of sux.  (But obviously isn't going to solve
long-standing security issues in the UNIX security model.)
2) Current su behavior encourages users to use insecure methods to get their
work done.
3) Aligns SUSE's su behavior with that of the other major PAM-based Linux
distributions.  This would make SUSE less surprising for users.

If there is interest, I can add a -X flag to my su patch which turns ON the
DISPLAY environment change.  This aligns the su behavior with the ssh behavior
and makes it possible for users concerned about X perms to alias "su" to su -x
and allow them to override with -X later.

IMHO the -X should be the default, shouldn't it?  The tunnel
for this X11 connection must not be encrypted as the ssh does
because this will cause trouble due encryption.

Well, the tunnel is local, so it's tough to listen in.  

I'm not sure how to do an analysis of which flag should be the default.  On one
hand, forwarding X perms can be a risky operation (although pam_xauth does take
steps to make it less risky by using the imports and exports files and not
forwarding perms for root), but on the other hand I worry that we'll be in the
same situation again -- different from other Linux distributions and without an
easy to find way to get permissions securely forwarded.

Is it better to be more secure by default but put users in a position to try and
work around the system, or is it better to be less secure by default to keep
users from trying to do less secure things?  I honestly dont know.

Hmmm ... for the user it should normally not notice which
type is the default.  AFA the DISPLAY and the XAUTHORITY
variables are set and any X application do work, the most user
do not have a reason not to use the su or the symlink sux.

On the other hand ... if any of the X application will not
work then the user will work around that ... in best case using
an option to switch the best security off ... in the worst case it
will be a ticket in the support and/or the user does not use the
best way anymore ... which is in both cases worse[tm].

Created attachment 24332 [details]
Allows su to transfer the X environment

Adds:
-x disable X forwarding
-X enable X forwarding

Documentation addition
--help now lists -x and -X
man page lists -x and -X
info page lists -x and -X

This should be the final version of the patch

AJ, 
should this be something for 9.3? 

This is a feature for 9.3. Andreas, please add to coreutils. 
Thorsten, I guess that's the right place, isn't it? 

About #29: "1) pam_xauth is community maintained" -> This is a lie. 

More concret about #36: pam_xauth is currently not maintained at all. 

*** Bug 60674 has been marked as a duplicate of this bug. ***

AJ,
if pam_xauth is not maintained (according to comment#36 ), do we still want it,
possibly having to maintain it ourselves?

"su -m" already preserves the environment.  There is no need for another  
option.  

Andreas,  I'm not sure I understand what you mean.  Are you saying that there is
no need to preserve the DISPLAY environment variable because a user can simply
use the "-m" option?

Or are you saying that the -x and -X option additions are not needed?

preserving the environment isn't enough, the x cookie hsa to be 
copied/added to the list of allowed clients to connect.  
 
preserving the environment doesn't magically allow you to connect 
to the x server. the x server expects a cookie. 

Thus nothing that su can do. 

Andreas, the patch attached to this bug forwards the X cookie and copies the
display environmeny variable.  This works with su.  I'm still not sure what
problems you are seeing.  Can you explain?

Which one? 

Fixed. 

<!-- SBZ_reopen -->Reopened by xkahn@ximian.com at Fri Jan 28 22:44:00 2005

Eek!  Andreas, the fix you checked in on Jan 20th gives us all the security
concerns with none of the gains.  You added pam_xauth to the su pam
configuration file, but didn't add my patch to su.  This means that the X privs
are being copied to the new account, but the environment variables aren't set
correctly and thus nothing works.  In other words, to the user it looks like X
doesn't work AND their session information can be stolen by an observant attacker.

When X is disabled with my "su" patch, it should have been stopping the X privs
from being copied.  I just found a bug in the code which meant this wasn't
happening.  I'll attach a fixed version.

If you really do not want to patch coreutils to fix this, I've come up with an
alternative patch.  "su" copies all the environment variables found in the PAM
environment list.  pam_xauth already adds XAUTHORITY to this list but it does
not add DISPLAY.  My "pam" patch solves this problem.  Note that if pam_xauth is
enabled on a machine (which is the default now, I gather) then the X privs will
be copied unless the .xauth/import or .xauth/export files specify otherwise, one
user is a system user, or root is the first user.  

Created attachment 28021 [details]
Add -[xX] to su to copy the X environment.

Fix a security flaw in the original patch.
If -x is sepcified, clear the DISPLAY environment variable BEFORE calling out
to PAM.  Otherwise the X privs will be exported anyway.

Created attachment 28022 [details]
Make pam_xauth copy the DISPLAY variable when copying X privs

This patch is alternative to patch 20021.  This patch actually applies to the
pam module, not the coreutils module.

Just setting DISPLAY does not grant any privileges.  If you don't want to pass 
X privileges just unset DISPLAY or use "su -". 

The pam_xauth module that you have now enabled to be on by default DOES copy X
permissions when users su to another user. (with some exceptions) However, it
does not preserve the DISPLAY environment variable.  Thus users will have their
X perms copied, but will not be able to use them unless they restore their
DISPLAY environment variable.  Patch 20021 allows controlling this from su,
Patch 20022 fixes pam_xauth to keep the display environment variable.

First question: Why does it works for ages for Fedora, RHAS and Mandrake 
and not for us with this configuration? 
 
Second: Patching pam_xauth is out of scope. If you wish a modified 
pam_xauth, get the patch upstream first. 

Hey Thorsten,  the Redhat code base (upon which all the examples you listed are
based on) simply copies the DISPLAY environment variable in su.  (Similar to my
patch, but does not include the requested -x/-X command line switches.)

Note that Redhat also doesn't change the PATH.

I'll attach RH's su.c and the pam patch they use to get it.

Created attachment 28114 [details]
Redhat's su.c file

Created attachment 28115 [details]
Redhat's su patch.

They grouped this in with their pam patch.

Sorry -- missed your second point.  pam_xauth is included as an additional
source to SUSE's pam modules.  The tarball appears to be a snapshot from
2003-07-24.  It doesn't appear that SUSE has been tracking updates, and since
the common usage seems to be to patch su, I don't believe the patch would be
accepted upstream.

I included the pam_xauth patch as an alternative solution to Andreas's worries
about patching su.

There is nothing to fix any more. 

Yes.  I have tested this and it works as advertised.  

issue is not fully addressed. 
 
Ludwig is working on it. 

I have filed two new su bugs on current behavior.  Are these the remaining issues?

Bug 66888 https://bugzilla.innerweb.novell.com/show_bug.cgi?id=66888
But 66893 https://bugzilla.innerweb.novell.com/show_bug.cgi?id=66893

And I've closed this two bugs as invalid because the DISPLAY
variable is reset if you're using `su -' ... this is a _know_
feature of su.

wrt su -: #66885 

*** This bug has been marked as a duplicate of 66885 ***

CVE-2002-1160: CVSS v2 Base Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)