The commit at:
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
Default assignee of xorg-team will cause mails to be sent there too!!
Created attachment 4894 [details] [review]
> 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
Solaris is shipping 6.9 now, which is also affected. What timeline are you
i think it's March 20, assuming we don't hit any more spectacular build system
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 ...)
that would probably be fine for us, i'll check with rel-eng.
When everyone here agrees with a new date, I'll inform vendor-sec.
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
For the monolithic tree, an advisory with a patch is enough. This is how
previous advisories were handled.
I've added firstname.lastname@example.org in the Cc: so everyone gets attention to the
discussion happening on bugzilla.
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
(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
whenever we push this i'll push 1.0.1 simultaneously, with the fix included.
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.
So everyone here agree to announce march 20 as new disclosure date to vendor-sec?
we can work with march 20.
march 20th would make our relengs a lot happier than april 6th.
right, unembargo is march 20th, 2006, at 1400 UTC.
Created attachment 4984 [details] [review]
modular patch, fixed filename
Created attachment 4985 [details] [review]
patch against 6.9
embargo lifted. fixed in 1.0 branch and in HEAD.
URLs for the fixed stable server:
patches are at:
md5 and sha1 in
gpg-signed, but the archives have probably stuffed that ten ways to tomorrow).
on Mar 25, 2017 at 15:28:50.
(provided by the Example extension).