Bug 195555 - Potential X insecure suid calls
Potential X insecure suid calls
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xorg-x11 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Depends On:
Blocks: 176344
  Show dependency treegraph
Reported: 2006-06-15 14:52 EDT by Josh Bressers
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2007-0317
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 13:33:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2006-06-15 14:52:48 EDT
From:    Marcus Meissner
Subject: [vendor-sec] setuid security problems in X


Dirk Mueller and I have been checking for setuid/seteuid without return

One offender who is exploitable we think is X. Both X.Org and XFree86.

For the readers who just joined a brief summary:

  In kernel 2.6 it is possible that setuid(user_uid); can fail even
  if done from root a process.

  Reason is that there is the maximum processes "ulimit" which is 
  honoured by setuid(), seteuid(), set*uid().
  If you do not check the return value and continue as-is you have
  not dropped the privilege, but run as root.

  An example of this has been released in "vixie-cron".

  Since ulimits on maximum processes are set by the kernel by default,
  any Linux 2.6 system is default affected.

  Fix: Check the return value of setuid() and handle it and/or
  check with getuid() right after the setuid() if it worked.

My evaluation might be off and it might not be exploitable in these

If this is exploitable I would propose an embargo of 2 weeks.
(Tue June 20th 12:00 UTC would be a nice date)

Critical MUST FIX problems:
./programs/Xserver/hw/xfree86/common/xf86Init.c:          setuid(getuid());
	Security relevant and critical.
	After this "sh -c "vtinit"" is called, which might be exploitable.

	(SUSE has the X Server setuid root, so this would affect us.)

./programs/Xserver/hw/xfree86/parser/write.c:			setuid(getuid()
        Security relevant and critical.
	Can corrupt any file on the system, like /etc/shadow.
	(I think via: Xorg -configure --... /etc/shadow)

./programs/Xserver/hw/xfree86/os-support/shared/libc_wrapper.c:        setuid(g
        Security relevant and critical.
	In xf86execl(), which I do not know who calls it.

./programs/Xserver/os/utils.c:	setuid(getuid());
./programs/Xserver/os/utils.c:	setuid(getuid());
./programs/Xserver/os/utils.c:	setuid(getuid());
        Security relevant and critical.
	These are in Popen(), Fopen(), System().

	Leak file content, start called programs as root.

All of them above are in the XServer.

Normal problems, but should be fixed probably:

./lib/X11/lcFile.c:	    if (seteuid(0) != 0) {
./lib/X11/lcFile.c:		seteuid(oldeuid);

./lib/xtrans/Xtranslcl.c:	setuid( getuid() ); /** sets the euid to the ac
tual/real uid **/
	Obscure, not used in modern systems.

./config/util/chownxterm.c:    setuid(getuid());
./config/util/chownxterm.c:    setuid(getuid());
	No setuid/setgid xterm used, we have utempter and devpts.

./programs/xdm/session.c:	setuid (verify.uid);
	This needs to be fixed, but is not security critical.

	It is called before the KRB5 tickets are dropped
	and the user auth is removed.

./programs/xdm/xdmshell.c:    setuid (geteuid());
	Should be fixed. In common use scenarios it is not setuid-root,
	so not critical.

./programs/xinit/xinit.c:		setuid(getuid());
	Security relevant.
	Must be fixed. This is critical when xinit is setuid-root,
	but I do not know if anyone has it so.

./programs/xload/xload.c:    setuid(getuid());
	Security relevant.
	No one ships xload setuid root anymore, but it should be fixed.

./programs/xterm/main.c:    seteuid(getuid());
./programs/xterm/main.c:    setuid(getuid());
./programs/xterm/main.c:    seteuid(getuid());
./programs/xterm/main.c:    setuid(getuid());
./programs/xterm/main.c:	seteuid(0);
./programs/xterm/main.c:	seteuid(getuid());
./programs/xterm/main.c:	setuid(screen->uid);
./programs/xterm/main.c:	    if (setuid(screen->uid)) {
./programs/xterm/misc.c:	setuid(uid);
./programs/xterm/misc.c:	    setuid(screen->uid);
./programs/xterm/os2main.c:	setuid(screen->uid);
./programs/xterm/os2main.c:	    setuid(screen->uid);
./programs/xterm/print.c:	    setuid(screen->uid);
	No one ships xterm setuid root anymore, but it should be fixed
	for those who do.

./programs/xf86dga/dga.c:   setuid(getuid());
	The old DGA binary, not shipped setuid root at SUSE.
	It does not do much exploitable afterwards, but it usually
	destroys your X session anyway, so it is better to not run it.

Ciao, Marcus
Comment 3 Josh Bressers 2006-06-20 14:44:02 EDT
This issue does not affect RHEL2 or RHEL3.  It should only affect RHEL4 and FC.
 I've not done any investigation if actual damage can be done with this issue. 
I don't understand the working of X well enough to say for sure.
Comment 4 Mike A. Harris 2006-06-20 15:52:21 EDT
Taking ownership.  We need to have bug reports for each OS release we need
to do an update for.  Right now, that looks like:

- RHEL-4
- Fedora Core 4
- Fedora Core 5
- Fedora devel

Is there a CVS for this issue?  I couldn't find one online.
Comment 5 Josh Bressers 2006-06-20 16:54:42 EDT
Before we file bug reports for other releases we need to understand if this is
actually an X secuirty issue.

Nobody has done an actual analysis of attack vectors for this problem.

The patches can be found in this mail:
Comment 6 Josh Bressers 2006-06-22 14:00:16 EDT
This is not a secuirty issue.  It turns out the places that the setuid is used
are not controlable by an attacker.

The upstream advisory mentions unchecked suid usage in several places.  We only
ship the Xorg executable suid root, which is the only potentially vulnerable

Here is a listing of the bad setuid() calls (provided by Marcus Meissner of
Suse).  The analysis was done by me.

./programs/Xserver/hw/xfree86/common/xf86Init.c:          setuid(getuid());
        After this "sh -c "vtinit"" is called, which might be exploitable.

We don't enable the vtinit command by default, nor would I expect anybody to be
using this configuration option.  Even if this ran as root it will rely on a
very insecure and poor configuration file option.

./programs/Xserver/hw/xfree86/parser/write.c:                   setuid(getuid());
        Could corrupt any file on the system, like /etc/shadow.

Only when Xorg is run as root can this codepath be reached; the setuid is a bit

        In xf86execl(), which I do not know who calls it.
        (There are #define execl xf86execl   in some files.)

All calls to execl (that are dangerous) are preceded by a setuid call.
They are the xf86Init.c call above, and the utils.c calls below.

./programs/Xserver/os/utils.c:  setuid(getuid());
./programs/Xserver/os/utils.c:  setuid(getuid());
./programs/Xserver/os/utils.c:  setuid(getuid());
        These are in Popen(), Fopen(), System().

The calls to Fopen should be safe.  The server uses seteuid if it's there,
otherwise it will fall back on setuid. (seteuid() is not vulnerable to this problem)

The calls to Popen and System are used by the keyboard map loading bits of
X.  There is no way for a user to specify a keyboard file (There is a
-kkbdb option which does nothing).  I can specify an existing keyboard map
(-kbmap), but the keymap file is verified and loaded long before the suid
call happens.

Comment 7 Matthieu Herrb 2006-08-31 02:26:36 EDT
I can confirm this analysis. Unfortunatly it came after X.Org released its

The only real world case where this is exploitable is 
the vtinit case, but it appears that no Linux system uses the 'vtinit'
configuration option to run a program.

However, OpenBSD developpers have brought to my attention that a systrace policy 
(and probably a SELinux policy or Solaris's DTrace) can make setuid() 
fail too for reasons other than process ulimit, so the checks are good 
to have anyways in case someone does something silly.
Comment 10 Søren Sandmann Pedersen 2007-01-08 19:08:37 EST
In cvs.
Comment 14 Red Hat Bugzilla 2007-05-01 13:33:53 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.