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
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.
Why are you running X11 on your servers?
Only one that they are telling us about...
If you want news from today, you have to come back tomorrow.
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.
Maybe it's an X11 server.
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).
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.
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!
OSX ships XFree86 4.3.0, which is not vulnerable.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
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.
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...
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.
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.
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)