Bug 242903 - CVE-2007-3103 init.d xfs script chown race condition vulnerability
CVE-2007-3103 init.d xfs script chown race condition vulnerability
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-xfs (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Kristian Høgsberg
: Security
Depends On:
Blocks: 492517
  Show dependency treegraph
Reported: 2007-06-06 08:08 EDT by Marcel Holtmann
Modified: 2009-03-27 04:03 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2007-0520
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 492517 (view as bug list)
Last Closed: 2007-07-12 05:18:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0520 normal SHIPPED_LIVE Moderate: xorg-x11-xfs security update 2007-07-12 05:18:55 EDT

  None (edit)
Description Marcel Holtmann 2007-06-06 08:08:46 EDT
From iDefense:

Local exploitation of a race condition vulnerability in init.d XFS (X Font
Server) script allows an attacker to elevate their privileges to root.

The XFS script is vulnerable to a race condition when it is started by init, or
by a system administrator. Specifically, it insecurely changes the file
permissions of a temporary file. This allows an attacker to make any file on the
system world writable.

Successful exploitation of this vulnerability results in an attacker gaining
root privileges on the affected system. However, in order to exploit this, it is
necessary for either the system to be rebooted, or for the administrator to
manually restart the XFS.
Comment 4 Josh Bressers 2007-06-11 11:33:06 EDT

Can you figure out where in RHEL[23] this directory is created?  It seems the
xfs binary is creating it, but I'm having trouble figuring out where in the X
source it's happening.  I've reached a point where I'm now just wasting my time
trying to understand this.
Comment 5 Kristian Høgsberg 2007-06-12 14:44:22 EDT
First of all, this is a very weak exploit.  It needs to run when xfs is started,
which you can't do as a regular user during startup, so all you can hope for is
somebody restarting xfs.  There's no reason to do so unless you install new core
fonts or update xfs.  So it's not remote exploitable and it only triggers on xfs

For RHEL 2 and 3, the directory is created by Xtrans, which is the worst library
ever.  It isn't even a library, it's a set of header files that you include and
they define a set of functions for accessing the network (they are the
_FontTrans* functions in xfs).  The RPM is xorg-x11-xtrans-devel.  Xtrans is
used by ICE and the Xserver too.

I think the reason we changed it in RHEL4 and 5 is that there's a DoS attack
where you can do 'touch /tmp/.font-unix' and prevent xfs and thus the X server
from starting.  Of course, you need to do a similar trick as in the exploit in
comment 1, since the xfs startup script deletes /tmp/.font-unix before starting xfs.

You can't atomically, forcibly create a directory if there's a file by that name
already, but we can loop in the script too, eg.

  while test ! -d $FONT_UNIX_DIR; do
    rm -rf $FONT_UNIX_DIR;
    mkdir -m 1777 $FONT_UNIX_DIR &&
      /sbin/restorecon $FONT_UNIX_DIR

Which additionally wont remove the dir when it's already there, eliminating the
race in most cases.  When the directory isn't there, it's probably the first
time the system boots.
Comment 7 Kristian Høgsberg 2007-06-15 18:36:33 EDT
xorg-x11-xfs-1_0_2-4 built in dist-5E-errata-candidate
xorg-x11-6.8.2-1.EL.19 currently building in dist-4E-errata-candidate
Comment 11 Mark J. Cox 2007-07-12 05:17:20 EDT
removing embargo
Comment 12 Red Hat Bugzilla 2007-07-12 05:18:57 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.