Bug 6213 - local user DoS and arbitrary code execution as root [CVE-2006-0745]
Summary: local user DoS and arbitrary code execution as root [CVE-2006-0745]
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg (show other bugs)
Version: 7.0.0
Hardware: All All
: highest critical
Assignee: Daniel Stone
QA Contact:
URL:
Whiteboard:
Keywords: security
Depends on:
Blocks: 5387
  Show dependency treegraph
 
Reported: 2006-03-10 19:24 UTC by Daniel Stone
Modified: 2006-03-21 18:10 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
obvious patch (755 bytes, patch)
2006-03-11 06:30 UTC, Matthieu Herrb
no flags Details | Splinter Review
modular patch, fixed filename (606 bytes, patch)
2006-03-18 08:34 UTC, Daniel Stone
no flags Details | Splinter Review
patch against 6.9 (640 bytes, patch)
2006-03-18 08:34 UTC, Daniel Stone
no flags Details | Splinter Review

Description Daniel Stone 2006-03-10 19:24:45 UTC
The commit at:
http://webcvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Init.c?r1=1.16&r2=1.17
introduced a couple of bugs.  Specifically, the test for geteuid == 0 will never
succeed, and the end result is that -logfile and -modulepath can be specified by
arbitrary local users, leading to DoS (-logfile /lib/libc.so.6), and arbitrary
code execution (-modulepath).

The fix is to change all geteuid == 0 or geteuid != 0 to geteuid() == 0 or
geteuid != 0.

This was only introduced in 6.9/7.0, and does NOT apply to 6.8.x and earlier.

First noticed by Alan Coopersmith.
Coverity ID: 4

The best candidate for unembargo date would seem to be April 6th, 2006, or April
13th, 2006 (if I'm remembering right that things are generally uncloaked on
Thursdays).
Comment 1 Daniel Stone 2006-03-10 20:11:56 UTC
ARGH!
Default assignee of xorg-team will cause mails to be sent there too!!
Comment 2 Matthieu Herrb 2006-03-11 06:30:01 UTC
Created attachment 4894 [details] [review]
obvious patch
Comment 3 Adam Jackson 2006-03-11 07:54:50 UTC
> introduced a couple of bugs.  Specifically, the test for geteuid == 0 will never
> succeed, and the end result is that -logfile and -modulepath can be specified by

more accurately, never fail.

we would strongly prefer to not wait a month to unembargo this, so we can avoid
shipping FC5 with a local root exploit.  who's actually shipping 7.0 in a stable
release?
Comment 4 Alan Coopersmith 2006-03-11 07:57:48 UTC
Solaris is shipping 6.9 now, which is also affected.   What timeline are you
looking at?
Comment 5 Adam Jackson 2006-03-11 08:26:24 UTC
i think it's March 20, assuming we don't hit any more spectacular build system
failures.
Comment 6 Daniel Stone 2006-03-12 05:35:52 UTC
so, ajax and alan, would an unembargo of friday the 17th give you sufficient
time to get your fixes through the processes?

(alternately, there could be an unembargo of friday the 20th, and rhat could
just take care to not ship before 1400 utc ...)
Comment 7 Adam Jackson 2006-03-12 08:15:02 UTC
that would probably be fine for us, i'll check with rel-eng.
Comment 8 Matthieu Herrb 2006-03-12 19:50:51 UTC
When everyone here agrees with a new date, I'll inform vendor-sec.
Comment 9 Alan Coopersmith 2006-03-13 04:02:34 UTC
I could get a preliminary fix out that hadn't passed QA and a security alert
telling people to just chmod 755 Xorg and only start it via gdm/xdm/dtlogin and
not xinit.   That's good enough for me to not object loudly.

I would prefer Monday March 20, since the 17th is an official holiday in at
least one country (and since part of our patch test/release team is in Ireland,
they'll be out that day), and an unofficial party day in others, such as the US.

ajax - are you going to release xorg-server-1.0.1 that day too?   Should we
bother with an entire monolith release just for this or just publish an 
advisory and patch with a note that it will be fixed in an upcoming 6.9.1
release?
Comment 10 Matthieu Herrb 2006-03-13 04:36:57 UTC
For the monolithic tree, an advisory with a patch is enough. This is how
previous advisories were handled.

I've added xorg_security@x.org in the Cc: so everyone gets attention to the
discussion happening on bugzilla. 
Comment 11 Daniel Stone 2006-03-13 20:52:04 UTC
i don't think an additional monolithic release is worthwhile, especially given
the immense difficulty of same.

so, are we agreed on the 20th for unembargo (standard time for unembargoing is
1400 UTC)?
Comment 12 Adam Jackson 2006-03-14 02:33:19 UTC
(In reply to comment #9)
> ajax - are you going to release xorg-server-1.0.1 that day too?   Should we
> bother with an entire monolith release just for this or just publish an 
> advisory and patch with a note that it will be fixed in an upcoming 6.9.1
> release?

whenever we push this i'll push 1.0.1 simultaneously, with the fix included.
Comment 13 Alan Coopersmith 2006-03-14 09:38:52 UTC
Right - I think the precedent of 6.8.1 for the single security fix was a bad one,
and should not be followed in general.
Comment 14 Matthieu Herrb 2006-03-15 00:59:04 UTC
So everyone here agree to announce march 20 as new disclosure date to vendor-sec?
Comment 15 Adam Jackson 2006-03-15 09:12:47 UTC
we can work with march 20.
Comment 16 Eric Anholt 2006-03-15 09:38:27 UTC
march 20th would make our relengs a lot happier than april 6th.
Comment 17 Daniel Stone 2006-03-18 03:56:47 UTC
right, unembargo is march 20th, 2006, at 1400 UTC.
Comment 18 Daniel Stone 2006-03-18 08:34:15 UTC
Created attachment 4984 [details] [review]
modular patch, fixed filename
Comment 19 Daniel Stone 2006-03-18 08:34:45 UTC
Created attachment 4985 [details] [review]
patch against 6.9
Comment 20 Adam Jackson 2006-03-21 01:04:09 UTC
embargo lifted.  fixed in 1.0 branch and in HEAD.
Comment 22 Daniel Stone 2006-03-21 01:30:18 UTC
patches are at:
http://xorg.freedesktop.org/releases/X11R7.0/patches/
http://xorg.freedesktop.org/releases/X11R6.9.0/patches/

md5 and sha1 in
http://lists.freedesktop.org/archives/xorg/2006-March/013992.html (also
gpg-signed, but the archives have probably stuffed that ten ways to tomorrow).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.