Weekly Edition
Return to the Security page
| |||||||||||||
Xorg-server 1.0.2 security fix release
It would appear that one of the bugs found in the recent Coverity scan was
a local root exploit in the X.org server
(version 1.0.0 and later). The X11R6.9.0 and X11R7.0 releases are also
vulnerable, though older releases are not. A 1.0.2 release has been made available with the
fix; expect updates from distributors in the near future as well.
(Log in to post comments)
Xorg-server 1.0.2 security fix release Posted Mar 20, 2006 17:13 UTC (Mon) by jg (subscriber, #17537) [Link] Note that people who have cut over to the modular release won't have to deal with replacing all their X environment this time....
Xorg-server 1.0.2 security fix release Posted Mar 20, 2006 17:19 UTC (Mon) by niner (subscriber, #26151) [Link] Users who just use end-user distributions won't have to, either.
Xorg-server 1.0.2 security fix release Posted Mar 20, 2006 18:33 UTC (Mon) by proski (subscriber, #104) [Link] Is that because the users don't care about local root exploits, right? Or you have a specific distribution in mind that has smarts to upgrade only some of the binary packages from the same source package? Or you mean that the "end-user distributions" ship older software (X11R6.8.2 and older in this case)?
Xorg-server 1.0.2 security fix release Posted Mar 20, 2006 19:24 UTC (Mon) by jg (subscriber, #17537) [Link] Generally, many/most distros have been reluctant to update a single package from the set generated from the X "tarball from hell", resulting in you getting every package for a single fix in one program...
This has as much to do with their internal release, testing and package numbering process, rather than any actual need to release all packages.
I for one, am very happy to see the last of the tarball from hell. And you can blame me for its genesis (though in those days, X sources were very, very much smaller).
Mystery cleared Posted Mar 21, 2006 5:27 UTC (Tue) by eru (subscriber, #2753) [Link] Generally, many/most distros have been reluctant to update a single package from the set generated from the X "tarball from hell", resulting in you getting every package for a single fix in one program...Aha, that's the reason why the urmpmi (or yum, apt-get...) upgrades for some small X11 bugfix always re-download clearly unrelated things, like font packages. I had long wondered why the distros I use (Mandriva and various RHEL-derivatives) are so wasteful.
Xorg-server 1.0.2 security fix release Posted May 4, 2006 0:34 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link] > I for one, am very happy to see the last of the tarball from hell.
You've got to admit that it was character building though. Especially on
Xorg-server 1.0.2 security fix release Posted Mar 21, 2006 10:57 UTC (Tue) by niner (subscriber, #26151) [Link] I mean that end-user distributions like SuSE have binary diff online updates, so such a fix is just a download of a few kilobytes.
Apart from that SuSE 10.0 really comes with X.org 6.8.2.
C hits you; you feel weak Posted Mar 21, 2006 5:37 UTC (Tue) by eru (subscriber, #2753) [Link] From the patch: - if (getuid() == 0 || geteuid != 0) + if (getuid() == 0 || geteuid() != 0) Sigh. Yet another bug that would not have existed if C had a slightly stricter type system, like keeping pointers and integers properly separated. Too bad the "Wirth" languages which did this (and more), and still were expressive enough for low-level work, got so totally supplanted by C.
That or the X11 build system Posted Mar 21, 2006 7:32 UTC (Tue) by Ross (subscriber, #4065) [Link] The type system isn't so flawed that it doesn't allow the compiler to detect this situation. If people only listened to compiler warnings...
There are multiple warnings which could apply here: comparing pointer vs. int, comparison between two constant values, and use function address (link-time constant, not a function pointer variable) in an expression. To the best of my knowledge gcc only reports the first of those due to usage of the construct to check for unresolved weak symbols -- which is something that screams for a builtin to make it clear when this is intended to happen both to the reader of the code and the compiler.
And, while I'm on the topic, I find it very unfortunate that C++ gives "0" two meanings: (int)0 and NULL. With that constraint, reporting the first warning would highly annoying due to false positives. Why couldn't they use a new keyword like "nil" which would make the type system even tighter?
Does X compile without -Wall? Are the warnings not checked? Does this not trigger a warning for some reason?
That or the X11 build system Posted Mar 21, 2006 8:07 UTC (Tue) by eru (subscriber, #2753) [Link] The type system isn't so flawed that it doesn't allow the compiler to detect this situation. If people only listened to compiler warnings...But it is so flawed! According to the C standard, 0 must be recognized as the NULL pointer constant (section 3.2.2.3 in the original ANSI C spec from 1989), and a lone function name is a valid pointer value. A C compiler cannot really start complaining about "pointer != 0" comparisons, because you would start getting a flood of warnings from perfectly correct code. As you later note, a special nil keyword would help, but only if the old usage of 0 as the null pointer is forbidden. Not backward-compatible. Another necessary fix to C type safety would be introducing a boolean type that is incompatible with pointers and integers (unless casted), and require all control structures to require it as the type of the condition. This would eliminate most = vs. == errors. But this will never happen, because it would not be backward-compatible.
That or the X11 build system Posted Mar 21, 2006 10:07 UTC (Tue) by nix (subscriber, #2304) [Link] GCC actually defines a special null builtin, which NULL expands to in C++ code: but this is identical to 0 except inasmuch as it affects warnings (it's used to warn about using NULL in arithmetic and passing NULL to functions expecting integral types). (Of course even if this were done in the C front end it wouldn't help code that didn't use it, like this. The compiler probably should warn about comparisons of non-weak symbol addresses to NULL, at least with an 'expression is always true'.)
That or the X11 build system Posted Mar 21, 2006 16:53 UTC (Tue) by Ross (subscriber, #4065) [Link] I have a hard time thinking of reasons to compare them with anything. Is there a legitimate use?
But about the other warning: based on the responses so far, I take it that there are no warnings generated.
Why can't GCC warn about integer to pointer conversion without the "special NULL" in C?
And, if that is for some reason impossible, why would the "special NULL" trick not work in C?
That or the X11 build system Posted Mar 23, 2006 1:17 UTC (Thu) by nix (subscriber, #2304) [Link] One word: stdargs. :/
The `special NULL' would work in the C frontend (after all it doesn't change the semantics of the language), but hasn't been implemented there.
That or the X11 build system Posted Mar 21, 2006 16:46 UTC (Tue) by Ross (subscriber, #4065) [Link] Ah, you are right about the standard, but your conclusion is wrong. It allows _either_ representation and requires the compiler to support _both_. Sure, 0 must be converted to a NULL pointer in several cases (but you could warn anyway), but the important thing is that it also accept (void *)0, NULL, or (type *)0.
So a compiler can generate warnings if "0" is used and it will actually be useful for most code because a naked zero is not the idiomatic notation. Contrast with C++, which is similar, but decrees that "0" is the one and true form of the NULL pointer, and _then_ you get into the situation where conforming code would generate too many warnings to be useful.
That or the X11 build system Posted Mar 21, 2006 9:00 UTC (Tue) by daniels (subscriber, #16193) [Link] The number of warnings is partially fused with infinity. We're fixing that, slowly. But in the mean time, there are just too many to even begin to think about it.
|
|||||||||||||