Slashdot Mirror
Homeland Security Uncovers Critical Flaw in X11
Amy's Robot writes "An open-source security audit program funded by the U.S. Department of
Homeland Security has flagged a critical vulnerability in the X Window System (X11) which is used in Unix and Linux systems. A missing parentheses in a bit of code is to blame. The error can grant a user root access, and was discovered using an automated code-scanning tool." While serious, the flaw has already been corrected.
Check the CVS server. OpenBSD 0wns again!
In related news, the Department of Homeland security has notifed 3497 people where their missing TV remote control is to be found, where your wife was until 3am last Thursday and have completed a record number of soduku puzzles in newspapers around the country.
Government officials were unwilling to cite their sources for this information instead choosing to simply say "we are watching you".
liqbase
They uncovered only one flaw? Sheesh.
Kudos to the heroes who painstakingly reinserted the missing parenthesis!
You see? You see? Your stupid minds! Stupid! Stupid!
A missing parentheses in a bit of code is to blame...the flaw has already been corrected.
Any word on exactly what the fix was?
Wanted: witty unique signature. Must be willing to relocate.
Shouldn't that be:
(X11 sucks monkey cock
Finally Homeland security has done something noteworthy. I'm glad this benefits the X11 community.
the answers you get depend on the questions you ask.
I wonder if Miles Papazian discovered the flaw by reading the binary or by utilizing a machine-coded matrix?
Why are you running X11 on your servers?
X11 is actually written entirely in LISP, and therefore there are too many parentheses for a mere mortal to ever get straight.
XML is like violence. If it doesn't solve the problem, use more.
Any word on whether this vulnerability is a risk for those using x11 within osx? TFA mentioned that the X windowing system shipped with OS X without stating what level of risk exists.
If the compiler doesn't have a problem with unmatched parentheses, to prevent any such problems in the future, simply insert) closing) parentheses) instead) of) spaces).
If you're wondering, here is the relevant SUSE security advisory from 21.3 - http://www.novell.com/linux/security/advisories/20 06_16_xorgx11server.html
Maybe it's an X11 server.
uh, you display it somewhere else.
if you said a + b * c but you really wanted (a + b) * c the compiler won't bleat.
Engineering is the art of compromise.
Actually, it was not a missing parenthesis, but a missing parenthetical.
double r;r = ( (double)rand() / ((double)(RAND_MAX)+(double)(1)) );
if ( r < 0.5 ) gotroot(true);
And the patched code:
double r;r = ( (double)rand() / ((double)(RAND_MAX)+(double)(1)) );
if ( r < 0.5 ) gotroot(true); (just kidding!)
In most cases the compiler will catch errors caused by typos and omissions, but it is perfectly possible to write code containing typos or missing characters which are still valid.
I had a quick look on Coverity's website and this appears to be the relevant line of code:
- if (getuid() == 0 || geteuid != 0)
+ if (getuid() == 0 || geteuid() != 0)
In the case of the first line, "geteuid != 0" is valid C code but checks whether or not the address of the geteuid function is 0.
The second line is what the programmer intended to write, which calls the geteuid function and checks the value returned by that function.
The problem (if there is one) lies with the language, not the compiler, since both of the above lines are legal C code.
Solutions to this kind of problem probably involve both a movement towards higher level languages (which are typically more verbose and don't allow low-level memory manipulation), and more extensive static code analysis. In the case of Xorg and the kernel, moving to a higher level language isn't really an option (not yet, at least).
Well, from TFA: "This was caused by something as seemingly harmless as a missing closing parenthesis"
So no, it is indeed just a closing paranthesis that is missing. Why exactly that bloke considered this 'seemingly harmless', I don't know though... that is rather like saying "The car crash was caused by something as seemingly harmless as a severed brakeline."
The impression I get is that it shouldn't be easily exploitable. By default, Gentoo (and any sensible distro) configures X11 to disable remote connections. Also, you should have some sort of firewall blocking the relevant ports anyway. If it is really exploitable, the attacker would probably need access to the machine anyway (at which point, you're largely already screwed).
a y/015136.html
Not reading the article doesn't seem to be much of a problem. It's really not very clear. For example, is this a problem with X.org X11 specifically? Is Apple's X11.app affected? The article just says the problem is with "The X Window System", without mentioning any particular implementations.
It took some digging to find the actual advisory:
http://lists.freedesktop.org/archives/xorg/2006-M
The fix was posted before, but the problem was that someone used "geteuid" rather than "geteuid()".
This results in making use of the function address rather than the return value of the function, which could cause difficulties.
That's gonna ruin someone's LTS system.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Please note that this exploit is for the local user only. If you are the only user on your Apple or Nix box, then this is a non-news item. However if the BSA, RIAA, MPAA, or Dept of Homeland Security has taken your box and wants root, then you might have a problem. ;-)
The truth shall set you free!
If you're running Gentoo stable, then you're safe: you've got Xorg 6.8.2, which is not vulnerable.
If you're running ~x86, then you've got the vulnerable version. It's a local exploit, one that is trivially simple for an experienced programmer to use.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
All of the affected versions are masked for testing under Gentoo, so chances are that you're not using an affected version anyway. In any case, it's evidently trivial for a local user starting an xserver to cause it to execute arbitrary code, but there's no way to attack a running server locally or remotely.
I wonder how many potential security holes Coverity's uncovered by scanning Windows source....oh wait....they can't. Well I'm sure if they signed an NDA they could tell M$ and get it fixed in a....um...err...sorry, you'll have to wait for the next patch cycle.
To Alcohol! The cause of, and solution to, all of life's problems.
This is from march, why is everyone freaking out now?
The advantage of open source shines through once again! This couldn't have happened with MS Windows, that's for sure... without access to the source code, this bug couldn't have been discovered, let alone fixed so quickly.
(And yes, I know that some gov't agencies have a deal to view the Windows source code, but there are WAAAY fewer eyeballs looking at it, and from what I've heard the code is a big badly documented mess.)
My bicyles
..I just saw a story on digg (washes mouth out with pee to get bad taste out of my mouth), and noticed that the FAA just announced they will be running linux to track flights. Maybe there is a tie in-between this find and that announcement?
Sig: I stole this sig.
is getting close to being able to do what they portray on 24.
Jack: I'm running out of time. I need that salelite image.
Chloe: I opened a socket into a NASA server and retasking the satelite.
Jack: Great, download the image to my PDA.
Chloe: I need your IP address.
Jack: 1.2.123.129
Chloe: I'm having some trouble. I'm hacking into a secure server at CTU, and sending the image to your PDA.
Jack: I've got it. Thanks Chloe.
Chloe: Whatever...
AFAIK this exploit can be used over the net, but only if you've enabled remote logins in your Xconf. I'm not aware of any distro that does that by default, and the Xconf "sample" that comes with XFree86 or Xorg both have remote logins disabled.
I realize that it's too much too assume that anyone geek enough to enable remote X sessions is also geek enough to protect his system adequately, but most of the time that will be the case.
Open Source for Open Minds
The problem (if there is one) lies with the language, not the compiler, since both of the above lines are legal C code.
Solutions to this kind of problem probably involve both a movement towards higher level languages (which are typically more verbose and don't allow low-level memory manipulation)
I think we can both agree Python is a higher level language. And guess what:
import os
if os.getuid() != 0 or os.geteuid = 0:
is completely valid. It's not high level vs low level languages here that's at issue. It's static verses dynamic typing and more specifically, strict verses weak static typing. If 0 wasn't treated so specially in C (it's the only numeric literal that's directly comparable to a pointer) this wouldn't be an issue.
Unfortunately, C++ made it even worse since the standard mandates that NULL is defined as:
#define NULL 0
Instead of at least:
#define NULL (void *)0
Depends,
Have you paid your Moses Fee?
(let my packets go....) [as sung to 'let my people go']
Less Talk. More Stab.
The effective UID (euid) is changed when you run a setuid app, while the real UID (uid in this case, or ruid) is not.
The effective UID is normally associated with permission to access files. Well, Linux actually uses the filesystem UID (fsuid or fuid) for that, but that one nearly always tracks the effective UID for compatibility.
There is also a saved UID (suid or svuid) that is helpful for apps that need to swap UIDs back and forth. It's not used for anything else.
Incidentally, that's the word you should have used too.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
In which case it won't be running the X server, which is the program in which this flaw resides. :)
There can't be a "missing parenthesis in X11" because X11 is not a piece of code, it's a protocol. This vulnerability only affects the X.org and XFree86 implementations of X11; there are many other implementations that are not affected.
It's pretty sad that Windows and Macintosh have conditioned people to think that every window system is just a piece of code; the notion that a window system could be an API standard with multiple implementations doesn't seem to occur tothem.
Tiger shipped with (X11 1.1 - XFree86 4.4.0) and X11R6.9.0 and X11R7.0.0 are forked from that. So it could well affect Mac OS X. If it does it will be interesting to see how long it takes Apple to provide an update if at all, given that it's open source
The exploit mentioned in this article cannot be exploited by a user who isn't logged into your system - you have to be able to run the Xorg command with certain options. See X.Org's advisory at http://lists.freedesktop.org/archives/xorg/2006-Ma rch/013992.html
Homeland Security was able to do the code audit on X11.
Maybe that really should be written as, because the source code was publicly available, Homeland Security was able to do this. How many of these types of faults exist in closed source software that no outside group had the chance to dig into like with X11 or OpenBSD or...
Graham
Yes.
Dewey, what part of this looks like authorities should be involved?
It's in code that allows you to do things like load code modules from other paths, so it's only allowed if you're already root or not running setuid-root. (It should probably check that you're not running setuid at all, but there's no real point having Xorg setuid to anyone but root, so no one has added that check.)
Rumor has it the ISO C++ committee is likely to pass through a proposal for a new keyword, nullptr, which will have a "magic" type "pointer-to-anything" and has the value of the null pointer constant.
// #1 // #2
// # calls #2 // calls #1
So, E.g.:
struct A;
int f( A* );
int f( int );
int m = f( 0 );
int n = f( nullptr );
Of course, that wouldn't help in the aforementioned case. 0 will still be convertible to a pointer type as it is now; it's just that 'nullptr', being a pointer itself, makes for a "better" conversion to a real pointer type.
nullptr is supposed to be a non-disruptive pure extension (except for the fact that it breaks code that uses 'nullptr' as an identifier) -- meaning that it should not change the meaning of existing code.
A linux terminal server need only the X libraries, not even a single instance of an X server, which generally requires elevated privileges to run. I think I've seen work to correct that, but as it stands at large an X server runs as root and has to arbitrate security, whereas X applications linked to X libraries, displaying to a thin client over the network, the server has no root level code and only the thin client filesystem/system is at any risk.
XML is like violence. If it doesn't solve the problem, use more.
Unfortunately, the distros compete with the likes of Windows. As such, though technically speaking X on a multi-user system of any remote importance is a bad idea, if you shrug off X on servers Windows administrators may not like it as much. Install Red Hat or SuSE server oriented distributions and by default you still end up with a X environment. Good administrators know not to run X and it is powerful and even more convenient to run X apps remotely or inside a detachable VNC session. For small business to medium business/departmental servers, expect X servers to be the norm in the enterprise despite best practice.
The obvious solution is X not as root, so the worst you can do is screw around with the devices X really needs access to (screw around with the graphics, and local input devices, but an administrator can still ssh and have an intact, secure system in the ways that matter)
XML is like violence. If it doesn't solve the problem, use more.
Starring Bruce Willis, of course, who assembles a crack team to go into the code and insert the missing punctuation before the world gets blown up.
That last one makes things tough. How can you have security when everything is known? Well, in practice that is the only context security is even possible. "Security through obscurity" really means "we don't know what our opponents know and we're not even sure what we know". If, however, you assume that your opponents know everything then you don't take shortcuts. You plan for contingencies, you have fallback positions, you have not just a plan but a roadmap of possibilities and how to deal with them.
(At least, for any scenario too complex to actually have a complete solution for. For simpler problems, such as a chess puzzle or - for the past decade - the entire game of draughts, it is possible to map a complete, guaranteed winning strategy that will work no matter what the opponent does. Such a solution exists for the complete game of Chess and indeed for the complete game of Go, but has not yet been found. For any given computer system, such a solution must also exist for the operator/admin, but the chief problem has always been to get them to bother even putting the bits of solution that are known in place.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
should be applied next, otherwise the bug is still there
That's the difference between closed source and open source I guess...
Critical vulnerability in X11, missing parens are to blame, report: "missing parens in code leaves X11 vulnerable, the problem is fixed."
--vs--
Critical vulnerability in Windows, missing parens are to blame (but that's under NDA), report: "the incompetent programmers of the Redmont monopolist did it again, your Windows is totally open to hackers due to a bad, bad vulnerability. While we're on this, let's discuss also how OSX and Linux are infinitely cooler than Windows will ever be, and how Windows users are clueless idiots."
Then the compiler is not compliant with the standard. Since it defined the constant 0 (and only the constant 0 not for example 1-1) in a pointer context as being converted to the NULL pointer at compile time. The only times 0 isn't correct is as an argument to a function with no prototype (which no one does anymore, right :) and as an argument to a varargs function call - since in both those cases there is no pointer context to trigger the conversion.
You need a better compiler.
In concept, there is a separate protocol and implementation of X. But the source has been available under a very permissive license since the very beginning. Because of this, the only thing I've ever seen that was reimplemented was the server (window server), everything else has just been compiled directly from the reference sources.
And even those window servers are compiled from sources derived from the reference sources, with patches.
Do you actually know of any implementations of X other than the two you mentioned? I tried to search for some and couldn't find any.
http://lkml.org/lkml/2005/8/20/95