COMMAND
	Insecure default pam_xauth for sh-utils priviledge escalation
SYSTEMS AFFECTED
	 su as contained in e.g. sh-utils-2.0.12-3.
	 RedHat pam packages like e.g. pam-0.75-18.7
	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.
PROBLEM
	Thanks to Andreas Beck [[email protected]] advisory :
	--snip--
	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.
	--snap--
SOLUTION
	 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.)