OSNews

Fixing the hole is one thing. Updating all those millions of installations of vulnerable X out there is another.

As for OS X ... last time I checked, they weren't running X11. By reading the latest news, though, you'd think that if you're running OS X, hackers will steal your house and first-born baby.

Heh.

I wasn't referring to how quickly X Window System gets patched on OS X, but to how quickly Apple patch the OS in general.

OK, so technically X isn't part of the (GNU/)Linux OS, either! But hopefully I'm getting my point across.

OK, so technically X isn't part of the (GNU/)Linux OS

Whenever it comes to security, "Linux" means just the kernel. When it comes to functionality, "Linux" means everything from KDE to Firefox to the Win32 libraries for Xine and the kitchen sink.

Come on, you've been here more than a month. You should know the ways of OSnews by now.

Heh.

"Fixing the hole is one thing. Updating all those millions of installations of vulnerable X out there is another."

One of the reasons people should just give up and use a "real" distribution if they're going to use *nix as a desktop OS.

I can't speak for others, but I had a nice little clean alert come from my notification area telling me updates were available. A couple were for X so I highlighted them and read change logs, clicked update, and was finished.

I'd imagine even Fedora would have such a nice system.

'a "real" distribution' being what?

A 'real distibution' probably meaning, one that is properly maintained; one of the big ones like Fedora, OpenSuSE, Debian and so forth.

It pretty much falls down to this, the less visible the distribution, the less accountability there is, so there for, the maintaines are more likely to be lazy.

For example, a vulnerability is found in X Windows, such as this one, two distributions fail to provide a speedy update, ones called Fedora, the others called Peanut Linux - which one do you think will get the post amount of flack? of course, Fedora, so there fore, if you want a distribution that keeps up to date with the latest fixes and security patches, you're better off getting a mainstream, highly visible distribution rather than relying on one that has been cobbled together by a guy operating out of a toilet cubical in southern siberia.

In this case, lazy developers would be fine as they'd still be on 6.8.x, which this vulnerability doesn't affect.

But that's a good point. The more used distributions are going to be more likely to get fixed quick.

Fedora is not a stable distribution, and is certainly not properly maintained. Maintenance cuts out after every new release, and new releases are made every nine months or so.. RedHat ES and WS are stable distributions. Fedora is just a testing ground.

OpenSUSE is more stable than Fedora, due to its lineage as a full, retail product, but in the long term I think SuSE Linux Enterpise Desktop (SLED) and Server (SLES) will be the truly stable distributions.

Debian, of course, is stable and well maintained.

Fedora is not a stable distribution, and is certainly not properly maintained. Maintenance cuts out after every new release, and new releases are made every nine months or so.. RedHat ES and WS are stable distributions. Fedora is just a testing ground.

Incorrect; firstly Fedora is a community based distribution, and secondly, there is a service setup called "Fedora Legacy" which supports releases all the way back to version 1 ( http://www.fedoralegacy.org/ ).

As for OpenSuSE; I doubt it; the eventual move will be to brand Novell as *the* linux distributor, they'll phase out SuSE branding in favour of Novell; and Novell will use the OpenSuSE as the basis of their commercial distribution.

I don't see anything wrong with the split between 'commercial' and 'community' - community can be controlled by its traditional 'roots' whilst the distributor itself can take the bits which it finds desirable, and make a commercial version out of it, coupled with support and application compatibility testing and support.

Incorrect; firstly Fedora is a community based distribution, and secondly, there is a service setup called "Fedora Legacy" which supports releases all the way back to version 1 ( http://www.fedoralegacy.org/ ).

Fedora Legacy does not cover all releases (in fact they're having serious trouble covering all releases) and are furthermore unofficial, separate from the core Fedora group, and separate from Redhat. While they're working as hard as they can, they're too few, and there's too many releases. You cannot rely on Fedora Legacy to keep your system secure. See these for more:
January 2006: http://lwn.net/Articles/168907/
April 2005: http://lwn.net/Articles/131982/
January 2005: http://lwn.net/Articles/119892/


As for OpenSuSE; I doubt it; the eventual move will be to brand Novell as *the* linux distributor, they'll phase out SuSE branding in favour of Novell; and Novell will use the OpenSuSE as the basis of their commercial distribution.

If you re-read my comment again, you'll see that I'm agreeing with you: i.e. that OpenSUSE will, like Fedora, become a testing ground for the full entreprise distributions for Desktop and Server. A consequence of this is that OpenSuSE, like Fedora, will cease to have any significant support (a new release every 9 months is not support).

I don't see anything wrong with the split between 'commercial' and 'community' - community can be controlled by its traditional 'roots' whilst the distributor itself can take the bits which it finds desirable, and make a commercial version out of it, coupled with support and application compatibility testing and support.

Again, you're not paying attention to what I wrote. Did I not list Debian - a completely free, community-supported distribution - as one of the sample stable distributions?

The point I'm making is that both Fedora and OpenSuSE are testing grounds for companies that aim to make money on products built on their foundation. As such they are geared to experimentation and rapid releases: in effect they're a perpetual beta. There is no promise of long-term (2+ years) support for Fedora, and I doubt that there will be for OpenSuSE. There is with Debian, and will be with Dapper Drake, but not necessarily with the Edgy Eft.

Therefore the stable distributions are Redhat AS, ES and WS, SuSE/Novell Linux Enterprise Desktop and Server and Debian. To a lesser extent, there is also Mandrake, but the company seems to have stagnated lately. Ubunutu has no track record, but it does have a lot of funds, so Dapper Drake, once it's released, may join this group (though I, frankly, would be wary of it).

Edited 2006-05-04 16:53

Any one of the major ones actually designed for desktop use.

"This was caused by something as seemingly harmless as a missing closing parenthesis," Chelf said,
I'm not a programmer, but that doesn't seem like something hard to fix.
Am I missing something?

No doubt fixing it wasn't the problem; just finding it.

Finding an aeroplane in an airport isn't hard, but finding it in a desert is.

I know that, but your original comment make's it sound like this wouldn't have been the case if it was closed source.
Maybe I just misunderstood your comment, sorry.

"This was caused by something as seemingly harmless as a missing closing parenthesis," Chelf said,
I'm not a programmer, but that doesn't seem like something hard to fix.

Wouldn't such code fail to compile?

Normally, but here a function and a variable had the same name "foo". So:

if (foo=0){do something}

should have been:

if (foo()=0){do something}

Normally, but here a function and a variable had the same name "foo". So:

if (foo=0){do something}

should have been:

if (foo()=0){do something}


But that is missing both the opening and the closing parenthesis. The article said, "This was caused by something as seemingly harmless as a missing closing parenthesis."

Yes, well, the article is wrong then. It was a whole pair of parentheses: geteuid instead of geteuid().

Even without the variable, I think foo would be a function pointer which would be non-zero, and therefore foo==0 would always be false. Remember that X is written in C, so lots of things that higher-level languages would catch might slip through.

At first I thought they meant a single ) parenthesis was missing, but it would had to have been a pair or the compiler would have complained.

Edited 2006-05-03 23:26

It is fixed. The offending lines were because they used geteuid as a pointer and not a function.

It looked like, but wasn't exactly:
if (geteuid)
...

Where it should be
if (geteuid())
...


C lets you do this, but it's very rare that you'd want to so security scanners look for it.

Of course, the check is if you're root (id 0, or false in c) so you can see how it's a priv escalation.
I'm not sure, but I think it only works if the X11 server is running as root. It is possible for it not to be, as OS X runs it when it runs it. And some do it on Linux and BSD as well.

Last time I checked the OS X version of x11 didn’t actually contain this bug, Apples version of X11 is based on Xfree 4.4 code, not the X.org X11R9 source code and therefore inherently doesn’t contain this error

Oh that's true. But I was saying that I didn't think it'd be vulnerable even if it was.

I'd be surprised if it didn't appear in XFree too. The code in question is directly derived from it -- I think you'd find that section of code appears identically in X.org and XFree.

I think I read somewhere that this had already been fixed

You did read it somewhere: the article itself, where they say that it was fixed within one week of being reported.

The other poster (Tom K) might well have thought that the OS X comment implied you thought OS X uses X11 not Quartz. Of course OS X do ship an X server on their install DVD and for those of us who have it installed it will be interesting to see how long it takes for their software update to install a patched/fixed version.

Edited 2006-05-03 22:09

Anyway, it does seem useful to have some automated checking in a project with as much code as Xorg. Hopefully the FSF doesn't freak like they did with the use of BitKeeper

I don't think that's much of a concern. These are two entirely different circumstances: in order to hack on the Linux source, you (as I understand it) had to use BitKeeper; a testing suite, on the other hand, is orthogonal to the ability to use or contribute to a project, and so it doesn't matter that it's not free except insofar as its existence reduces motivation to write a free alternative.

Coverity probably is doing this for the publicity, but that doesn't mean it's not valuable. They're also scanning several other projects[1], including Wine, and have helped uncover many bugs.

http://scan.coverity.com/

True, but at the same time, Coverity don't do it out of the goodness of their own hearts, they use it to improve its bug finding capabilities - for example, in the wine scan, there were a number of 'bugs' that weren't really bugs, for example, and coverity will use the feedback from wine to adjust their bug searching too to take into account odd programming approaches rather than miss detecting them as bugs.

Edited 2006-05-04 01:47

Now, my question is ... unless they have a declared variable called 'geteuid', which would be STUPID, why didn't GCC error out with a "variable undeclared" error?

getuid != 0 checks if the address of the getuid function is 0, but the code was supposed to check if the *value* of the function was 0.

Because functions are pointers.

int (*myGeteuid) () = geteuid;

That statement is legitimate, and you do do things somewhat like it every now and then.

You're not a c programmer are ya?

Haven't done it seriously for about 7 years now. :-P

Thanks, though. I get it.

A function designator is converted to a function pointer. So given void f(void), f == &f.

GCC does flag it. Unless you set the error level, though, it's a warning rather than an error -- because that's the way C is supposed to work. This is perfectly valid:

if (printf == 0) { /* do something */ }

... assuming you included stdio.h, because printf is a pointer to a function and the conditional is testing to see if the pointer is null. The only problem is that the two items are not of the same type, so a warning is issued by the compiler. That warning can be made into an error by setting the proper option.

The real problem here is that X.org doesn't yet compile without warnings. So many warnings, in fact, that you miss warnings of situations that could easily be errors (such as the one cited in the article).

C99 specifies, like C++, that 0 is a null pointer constant. A null pointer can be converted to a null pointer of another type. So the function designator is converted to a pointer to a function returning type T, the null pointer constant 0 is converted to a null pointer to a function returning type T, and the comparison is performed. The standard, IIRC, dictates that a null pointer is always unequal to a function. This would imply, the rules regarding conversion of a function designator (that is except in conjunction with sizeof and &) to a pointer to a function not withstanding, that such a comparison would be superfluous and deserving of a warning while the comparison with 0 would not.

Who's justifying the bug? I don't see anybody justifying the bug. It's a bug, it was serious, it was fixed. Nobody's justifying it.