Red Hat Bugzilla – Bug 242903
CVE-2007-3103 init.d xfs script chown race condition vulnerability
Last modified: 2009-03-27 04:03:33 EDT
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.
Can you figure out where in RHEL 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.
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 &&
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.
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
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.