Just-Announced X.Org Security Flaws Affect Code Dating Back To 1987 172
An anonymous reader writes Some of the worst X.Org security issues were just publicized in an X.Org security advisory. The vulnerabilities deal with protocol handling issues and led to 12 CVEs published and code dating back to 1987 is affected within X11. Fixes for the X Server are temporarily available via this Git repository.
Wha?!?!!! (Score:5, Funny)
Re:Wha?!?!!! (Score:4, Funny)
Because Xorg is beautifully programmed and easy to understand so any programmer can quickly contribute to it's code.
Re:Wha?!?!!! (Score:5, Insightful)
All million lines of it ;)
Seriously, I'd really love to go in myself and fix the bug that's currently preventing me from using GLX [freedesktop.org], but I wouldn't even know where to begin. I think Xorg is seriously understaffed in terms of volunteers compared to the scale of the project - it looks like most bug reports don't get responses for months or years, if ever.
Re: (Score:2)
Why do you think those same developers decided to create wayland? X is a disaster of legacy code and it's far more work to fix it then it is to just replace it.
Re: (Score:2)
I'd love to see some example workflows of how you work on something like X - or the kernel, for different classes of bug hunting. It's the type of thing I've always wanted to dive into, but just the thought of trying to get to the stage where I can tweak/run/debug is incredibly daunting.
Re:Wha?!?!!! (Score:5, Interesting)
Just did... looks like my estimate of "a million lines" for Xorg was a bit off. It's "only" half a million lines of code (481739), plus 88k lines of comments and 87k blank lines, in 1476 files.
Re: (Score:2)
Your estimate was probably just a bit old, if I recall it was something like 800k when x.org took over from xfree86, they shaved off hundreds of thousands of lines of old cruft. And when they finally ran out of cruft that could be removed, they started writing Wayland. It's probably the only OSS project that's shrunk over the last 10 years,
Re: (Score:2)
Ooh, found it in this video [youtube.com] from 15:03, allegedly it was 1.1 million but there's no repository dating that far back to check however:
xserver1.0.2: 879403 LOC
xserver now (july 2013): 562678 LOC
Re:Wha?!?!!! (Score:5, Insightful)
It's open source! Surely dedicated multitudes of programmers have been dutifully poring over the code for decades, searching high and low for potential flaws because ... well, just because it's there! Surely!
To be blunt, that's exactly why this was found. If it were closed source, the bugs would still be in there.
Re: (Score:1)
To be blunt, the vulnerabilities were only disclosed so the finders could collect the bounty.
Re: (Score:3, Interesting)
To be blunt, it took over 26 years to find even with the source code and all the programmers on the planet who could to look at it.
If it were closed source, the bug probably wouldn't exist anymore because closed source probably doesn't keep using code that's two-and-a-half decades old. As examples, OS X has nothing from Mac OS classic and Windows 95 is long gone from modern Windows version. Or at least I would hope so.
Re: (Score:2, Informative)
Re: (Score:2)
Microsoft is famous for reusing less code that most other software shops. On top of that the present Windows systems are a derivative of Windows NT not Windows 95, so I think it would be a safe bet to say that presently Windows contains comparatively little code from Win95.
Re: (Score:2)
Re: (Score:3)
Windows 7 was the product release of the beta version otherwise known as Windows Vista.
Re:Wha?!?!!! (Score:5, Informative)
Re: (Score:1)
"Windows 95 is long gone from modern Windows version. Or at least I would hope so."
Sorry, you are completely and utterly wrong and clearly don't have a clue what you are talking about.
Re: (Score:1)
OSX could potentially suffer from anything Unix/BSD does since that's the linage it comes from. not OS8/9, a bug could in theory be from 1970....
Windows most certainly reuses code. Notice how often when a patch was release the same patch would go for multiple operating systems, even back in the 2000 era. Look at some of the latest IE bugs the same bug would be in IE6 to IE11. I'm on 8.1 and I just searched my Syswo64 folder and found a dll from 2000 some sql management thing, not part of the OS, but still a
Re: (Score:2)
Re: (Score:3)
I wouldn't be so sure about that.
On the mac while "classic" mode is gone "carbon" is still there and was explicitly intended to allow porting of code from classic macos. I'd be surprised if there wasn't some code that had been written for classic macos still in there somewhere.
Similarly win32 was designed as a 32-bit variant of win16 and i'd be very surprised if there wasn't still some old code hanging arround somewhere.
Re: (Score:2)
Similarly win32 was designed as a 32-bit variant of win16 and i'd be very surprised if there wasn't still some old code hanging arround somewhere.
Like the basic types, where a WORD is 16 bits and a DWORD is 32 bits, which is sprinkled everywhere throughout the entire OS.
Re: (Score:2)
An 8-bit value is called a byte and we do need words to describe 16-bit and 32-bit values, regardless of the maximum allowed by the CPU.
Re: (Score:2)
An 8-bit value is called a byte and we do need words to describe 16-bit and 32-bit values, regardless of the maximum allowed by the CPU.
Call a 16-byte value a half-word. The only reason it's called a WORD on Windows is because of legacy backwards-compatibility issues.
Sorry man, your utopia where everyone uses new code is a fantasy. There is trillions of dollars of code already out there, and no one wants to spend trillions of dollars to rewrite it all.
Furthermore, I don't even understand why you would want it all to be rewritten. If it's bad code, certainly; but if the code works, then rewriting it will add new bugs.
Re: (Score:2)
Why would a 16-bit value be called a "half-word"? It's always been a word and 32-bit has always been a double word. You're the one asking to use a new code with your half-word.
Someone screwed up when we went with 32-bit CPUs and people kept saying that a word is the maximum value for a CPU. We're using 64-bit CPUs now, so that means a half word would be 32-bit and a 16-bit value would be a quarter word. You can't try to change the meaning of a word with every CPU upgrade otherwise that's when you need to re
Re:Wha?!?!!! (Score:5, Informative)
Why would a 16-bit value be called a "half-word"? It's always been a word and 32-bit has always been a double word. You're the one asking to use a new code with your half-word.
I think you're drunk or something, you keep on saying stuff that could be easily figured out if you looked it up on Wikipedia.
A 'word' is the natural unit of data on the CPU architecture (not the maximum). Thus on a 16 bit computer a WORD is 16 bits, but on a 32 bit computer it's 32 bits.
Even a byte was not necessarily 8 bits before OS/360, it commonly was found as 7 bits, or even four bits.
Re: (Score:2)
So a 'word' is a completely useless unit because it keeps changing depending on the CPU.
It's not useless any more than telling someone "I am here" is useless. Now, saying that a WORD is exactly 16 bits and expecting that to be portable; you are completely right, that is a silly thing to do. All the more so because Microsoft had just recently gone through the switch from 8 bit words to 16 bit words (Altair was an 8 bit computer).
I've never seen byte (octet) being anything other than 8 bits.
That doesn't surprise me at all. And yet they existed.
Re: (Score:2)
You know, 'word' actually means something, and it never referred to a particular number of bits - it was always a property of the architecture. Generally, word size == register size == memory address == unit of memory that can be operated on. 32-bit machines are 32-bit because they have 32 bit registers, and the size of a memory address is 32 bits long (=4GB), and you can't move less than 32 bits to/from RAM.
So, yeah, it absolutely depends on the CPU, because it's the fundamental unit of the CPU. It's actua
Re: (Score:2)
You know, 'word' actually means something, and it never referred to a particular number of bits
Unless you're using the Win32 API, then WORD is a constant type of exactly 16 bits. And a DWORD is exactly 32 bits.
Re: (Score:2)
Yeah, but the WORD type hasn't had a relationship to the actual word size for 20 years. As you said upthread "The only reason it's called a WORD on Windows is because of legacy backwards-compatibility issues."
It was stupid for them to lock processor-dependent stuff into the API and it means you get these ridiculous anachronisms. Especially ridiculous that "WORD" is intended to mean a fixed-size value, when "word" is defined by its processor-dependence. The API is full of this nonsense - WPARAM and LPARAM or
Re: (Score:2)
It was stupid for them to lock processor-dependent stuff into the API and it means you get these ridiculous anachronisms.
So true.
Re: (Score:2)
register size == memory address == unit of memory that can be operated on.
Every modern processor i'm aware of can operate on memory in 8-bit units despite having 32-bit or 64-bit register sizes and 32-bit or 64-bit memory addresses. Older processors with 8 and 16 bit register sizes typically had memory address sizes larger than their register size.
Re: (Score:2)
P.S.: I think the use of the word "WORD" makes things confusing in the first place.
Re: (Score:2)
It's a holdover from the VERY old days of computing.
http://en.wikipedia.org/wiki/W... [wikipedia.org]
Re: (Score:1)
I wouldn't be so sure about that.
On the mac while "classic" mode is gone "carbon" is still there and was explicitly intended to allow porting of code from classic macos. I'd be surprised if there wasn't some code that had been written for classic macos still in there somewhere.
Similarly win32 was designed as a 32-bit variant of win16 and i'd be very surprised if there wasn't still some old code hanging arround somewhere.
While technically still there, the Carbon API has been officially Deprecated since 2012 [wikipedia.org], and as of OS X 10.8 (Mountain Lion), is clearly on its way out.
It's a shame, because it was a brilliant piece of work (but also not without its problems); but the writing was clearly on the wall when it wasn't ported to 64-bit in 2007.
Re:Wha?!?!!! (Score:5, Insightful)
If it were closed source, the bug probably wouldn't exist anymore because closed source probably doesn't keep using code that's two-and-a-half decades old. As examples, OS X has nothing from Mac OS classic and Windows 95 is long gone from modern Windows version. Or at least I would hope so.
There are 300billion lines of COBOL still in production. [freschelegacy.com] And every time you transfer money through banks, your money passes through it. OSX has code from the 90s in it, and Windows has code from the 80s.
Pretty near every bad software practice that you find in open source software is also found in closed source software.
Re:Wha?!?!!! (Score:4, Interesting)
Actually, OS X contains code and bugs that date back to the 1970s [computerworld.com].
Re: (Score:2)
Re: (Score:1)
OS X is an evolution of NEXTSTEP, which was started in the late 80s. They saw that OS 9 was a dead end and Apple needed something "new" and "modern", so they went with NEXT (and for a good while there was this set of compatibility APIs called carbon, PROBABLY had a lot of mac classic code). You can still see a lot of similarities between Xcode today and what they were using on NEXT in the early 90s.
new code, old code, it makes no difference. It ALL has flaws.
Re: (Score:2)
OS X is an evolution of NEXTSTEP, which was started in the late 80s. They saw that OS 9 was a dead end and Apple needed something "new" and "modern", so they went with NEXT (and for a good while there was this set of compatibility APIs called carbon, PROBABLY had a lot of mac classic code). You can still see a lot of similarities between Xcode today and what they were using on NEXT in the early 90s.
new code, old code, it makes no difference. It ALL has flaws.
Heck even the images from the "Grab" program in the recent versions of OSX have the original Grab icon from NeXTSTEP [osxdaily.com]
Re: (Score:2)
Heck even the images from the "Grab" program in the recent versions of OSX have the original Grab icon from NeXTSTEP [osxdaily.com]
But now, it's just nostalgia. Like Clarus the DogCow [chez-alice.fr].
Re: (Score:1)
new code, old code, it makes no difference. It ALL has flaws.
open code, closed code, it makes no difference. It ALL has flaws.
Just as true.
Re: (Score:3)
Actually that's not true, as demonstrated by the MS14-064 (it's a bug that affects Win8 and also Win95).
As a sidenote, Win95 is not an ancestor of Windows8. Win8 is a member of the WinNT family, its lineage going back to the first version of Windows NT, which was curiously called Windows NT 3.1 (released in 1993).
The other line of Windowses (the one going from Windows 1.0 to Windows ME) ran in parallel and the two families sometimes shared some code but th
Re: (Score:2)
Windows NT has a lineage dating back to April 1987 with the release of OS/2 1.0
Re: (Score:3)
I am not a Windows developer, but I have been a long-time tinkerer and user. The 32-bit versions of Windows, even up to and including the previews of Windows 10, still include the same old NTVDM that provides support for 16-bit DOS and Windows programs. I've personally played around with running completely unmodified copies of MS-DOS Executive from Windows 2.x and 3.0, Program Manager, and various other ancient things with absolutely no trouble. This likely includes some very old code to allow this old stuf
Re: (Score:2)
I read somewhere that NTVDM isn't supported in x86-64 because "long mode" won't execute "8086 Virtual Mode".
Yet supposedly MS could resurrect the software for 64 bit Windows by running the software via the VT-x CPU extension present in most recent x86-64 CPU revisions.
But I guess the effort to make the NTVDM subsystem 64 bit clean isn't worth it...
Re: (Score:2)
I'd guess the intersection between users who require 64-bit Windows on a processor that supports VT-x and users who require the use of 16-bit programs that won't work in a virtualized environment is pretty small. Plus I suspect Microsoft likes the reduction in attack surface in removing all the old cruft, even if it could technically be reworked to run.
Re:Wha?!?!!! (Score:5, Funny)
How dare you question his credentials! He's worked for no less than TEN startups, and he's never seen code that's more than three months old before it gets sold off and the company shuts down. That's 10 samples, statistically significant compared to whatever silly anecdote you've got from working at some hidebound behemoth like SAP or IBM for a decade! These posers don't even count!
Re: (Score:2)
To be blunt, that's exactly why this was found. If it were closed source, the bugs would still be in there.
I disagree with this type of statement that paints all closed source code as bug ridden by default.
If the code is closed source then the amount/type of bugs in it is unknowable by the public.
Re: (Score:2)
I disagree with this type of statement that paints all closed source code as bug ridden by default.
To be fair, most of it is. You even have guys at Google saying that bugs are no big deal [google.com].
Re: (Score:2, Interesting)
To be blunt, that's exactly why this was found. If it were closed source, the bugs would still be in there.
The bugs could potentially be found no matter if the software was open or closed-source. There is no evidence that proves your statement, unless of course you happen to work for Xi Graphics (authors of the closed-source X windows server, a.k.a. Accelerated-X [wikipedia.org], which is what the free XFree86 was supposed to supercede) and have a story to share there.
The point the OP was trying to make was that Linus's Law [wikipedia.org], specifically Eric S. Raymond's "given enough eyeballs all bugs are shallow" argument, is ridiculously i
Re: (Score:2)
Re: (Score:2)
I agree, And to simplify this, testing doesn't prove or disprove the existence of bugs. If a bug is obtuse enough (like most security holes), there is a good chance it won't get tested even in day to day use. Most code over a few hundred lines gets sufficiently complex that it starts to take a real effort to do a code review. Couple that with the fact that one needs experience and/or training to read code and recognize security flaws; and most programs are thousands to tens of thousand of line long, or more
Re: (Score:2)
I disagree that it is a ridiculously idealistic statement. It is more of a misunderstood rhetorical tautology than anything else.
A discovered bug obviously had en
Re: (Score:2)
I disagree that it is a ridiculously idealistic statement. It is more of a misunderstood rhetorical tautology than anything else.
A discovered bug obviously had enough eyeballs on it, and an as yet undiscovered bug hasn't had enough eyeballs on it.
Actually, I wish he had limited the statement to the persistence of known bugs in FOSS code bases. ESR said the bugs are easier to find as the number of beta testers and developers increases. This doesn't appear to be true. One thing that is true is that code quality is viewed differently in FOSS than in commercial, proprietary software. All too often, software businesses treat QA, debugging and code maintenance as overhead, so there's a perverse incentive to leave known bugs - even the most egregious ones
Re: (Score:2)
Re:Wha?!?!!! Yup, you betcha! (Score:5, Interesting)
MS has had a fully-supported "no GUI" server option since Server 2012, but has been possible to admin CLI-only, without 3rd part add-ins, since 2008 (though the GUI would still be running, if you don't provide remote access to it, it might as well not be), and with 3rd-prty add-ins since 2003.
However, managing multiple Windows servers is more about group policy than logging into any servers, GUI, CLI, or carrier pigeon. I've worked with management systems for 1000s of Windows servers, and the only reason you'd ever log into a server is to recover if something went horribly with a new deployment, and you wanted to find out why (to debug your deployment - just recovering the server was automatic).
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I am not sure why you think rewriting in a different way is the solution. One could also refactor and fix bugs (which is being done).
For example the implementation of the core X protocol has been described as good by the guy who found these bugs (because
bugs have already been fixed in the past). New code will not automatically be better: E.g. compare his comments about Qt and KDE.
From looking at it superficially, Wayland seems to be a pretty good code quality though. I am just not too much a fan of breaking
Re: (Score:2)
No, because the X11 programmers said 'who wants to be fixing bugs in crusty old code when we could be working on the New Shiny Wayland instead?'
In before the trolls (Score:5, Insightful)
Open Source does not guarantee that all of the bugs will be found, it merely guarantees that all of the bugs can be found.
Re: (Score:2)
Open Source ... merely guarantees that all of the bugs can be found.
Well it seems like Closed Source "merely guarantees that all of the bugs can be found" by crackers. (NO, they're not hackers.) They seem to do a pretty good job of finding and exploiting problems withOUT any copy of the source for reference.
(Well, I presume they don't. Maybe Bill Gates has a whole independent second fortune that we don't know about. Or: how DID Balmer afford to pay $2B for a bunch of guys walking around while bouncing a ball?)
Re: (Score:2)
It is better because the bugs are more likely to be found and fixed. Note that more likely is not at all the same as 100% likely.
Re: (Score:2)
If every version of Windows had a flaw, how many of them could you fix?
Re: (Score:2)
Exactly my point. However small the chance that I will spot and fix a flaw in Free Software, the odds are better than that I will find and fix a bug in proprietary software where I am not even allowed to look at the source.
so much for open source bug discovery being better (Score:1)
One of the big claims is because you can't look at closed source code, bugs go undetected for longer.... 1987?
Re: (Score:1)
Re:so much for open source bug discovery being bet (Score:4, Insightful)
Zealots are deniers.
The problem is there are enough vocal Zealots to proclaim that how a product is licensed some how makes it superior/inferior to an other.
But in general the more confident you are in your products superiority, the more problems you ignore or don't bother looking for.
Re: (Score:2)
Well if the new radio's are smaller, lighter and do not need to be (better components, less moving, or parts that can move...) repaired, and offer near identical sound. Then Yes your old radio is inferior to the new one.
Re: (Score:2)
What about XFree86? (Score:2, Funny)
Or is that project even still around?
Re: (Score:2)
Wow. Nevermind. It died in 2008. Y'all, I'm old and time slips by me pretty quick. Sorry.
Re: (Score:2)
Man, don't scare me. What should i consider "old"?
It's a state of mind really. I'm 61 and could be called old, hell I get senior discounts now.
I have no illnesses and feel as well as I ever have, or I could dwell on every ache and pain and start acting like I was 61 instead of a "kid" (say 35 yrs old : } ) still.
Re: (Score:2)
Which is too bad.
I was able to get XFree86 to work on the stuff that autodetect just fails on.
In most particular is my old netbooks 1024x600 resolution monitor which it wants to me to run at 800x600 stretched.
Re: (Score:1)
X.org started from a fork of XFree86, so it wouldn't make any difference.
original story (Score:3)
Original story:
http://it.slashdot.org/story/1... [slashdot.org]
CCC talk:
http://media.ccc.de/browse/con... [media.ccc.de]
So what does it affect? (Score:3)
So, what exactly is impacted here? Are all X11 implementations affected, or just XFree86 and X.org? I'm seeing SGI sources listed as impacted, which would point to any X11 implentation that uses GLX being impacted (including Xsgi on my IRIX systems), and seeing the age of the bug, I would imagine it would be more proper to point to things based on XFree86 rather then X.org. People forget that X11 is bigger then X.org, and the X.org team wasn't always the only game in town (if they didn't have a monopoly we wouldn't be arguing about Wayland....).
Re: (Score:2)
Since the code that had the vulnerability was originally reference code, it is quite possible (but not known) that proprietary implementations also have the bug.
Re: (Score:1)
It is a while ago (more than 20 years!), but I am certain that we fixed most of the issues described in CVE-2014-8092 and CVE-2014-8095 when porting X11R4 and we did report those bugs to the X Consortium (actually a precursor of Xorg.)
I am also quite sure that the large companies (Sun, SGI maybe IBM) also fixed and possibly reported those bugs. I can only conclude that the software engineering practices of the X developers were a bit sub-standard, even for those days and it also makes me quite suspicious a
Re: (Score:2)
Mind if I ask which porting project you were a part of? There used to be quite a bit of X11 implementations.
X11? (Score:2)
Just to clarify, if we use X10 we're good?
Re: (Score:2)
Wait til you see X12.
News at 11!!! (Score:5, Informative)
Anybody who's really looked at security around X11 has known for decades that it isn't that great.
I even remember that as recently as a year ago, ATI's drivers specifically tell you to use "xhost +" to enable GPU compute jobs using ATI devices, which resulted in a lot of "LOL NOPE" in the HPC industry. (It's trivial to root a machine that has had "xhost +" executed inside an X11 session.)
X11 having critical security holes should surprise no one. There's a reason internet-facing servers don't have X11, and it's not just because you don't need a GUI sucking up resources.
On the other hand, I'm thoroughly grateful that somebody decided to do something about it.
Guess I'm finally goinna have to update to X11R5 (Score:2)
Just tell me that Motif is still safe.
Re: (Score:2)
Well....I would stick with OPEN LOOK just to be sure.
I just wish (Score:2)
Re: (Score:1)
Configure the X server to prohibit X connections from the network by passing the -nolisten tcp command line option to the X server.
Well duh!
Re: (Score:3)
Doesn't prohibiting network connections to the X server rather defeat one of the major features of X?
Granted, I think I usually am tunneling my X connections through ssh, so perhaps this doesn't apply as widely as it did a few years ago.
Re: (Score:2)
Yes, most Linux distributions seem to have used -tcp nolisten for quite a while. ssh -X still works fine and is very useful (IMHO).
Re: (Score:2)
Yes, most Linux distributions seem to have used -tcp nolisten for quite a while. ssh -X still works fine and is very useful (IMHO).
Very long time. Most typical server installations don't even install X, so if you are wanting to exploit this, you are going to have to look really hard for somebody on your LAN running an ancient distro who's disabled the firewall and other remote auth stuff.
Re: (Score:2)
These days for heavy remote X use you use stuff like Xpra, also over SSH, as it can leverage hardware encoders which the X protocol didn't have at its disposal back when it was designed.
Re: (Score:2)
Temporarily disabling a feature is not the same as permanently doing so. It's like saying that you always need to run as root. You don't. You only need to enable root level access when it's actually needed. The same goes for outward facing network services.
Similarly MacOS doesn't enable the ssh server by default.
Re: (Score:2)
I USE remote X connections. Mostly over the LAN.
Re: (Score:2)
Why can't you use ssh -X ?
Re: (Score:2)
I commonly use XDMCP because it's simply easier and faster for a handful of the systems I work with (given, the SGI's are quite slow by today's standards...). Also trying to explain that to some Windows people when they insisted they needed to install Oracle DB on Solaris systems (they wanted me to tell them how to get a remote GUI on Solaris 9 and 10) it was far easier to point them to XDMCP.
Re: (Score:3)
Re: (Score:2)
Yes.
Re: (Score:2)
That's not a problem that is unique to Linux however. Many commercial products have the same issues - the marketing and planning people want new features as that helps them sell upgrades and maintenance, and in the past those sorts of things were prioritized higher than things like a security audit which management concluded weren't something that one could sell.
It is only when customers demand security audits of the products that they buy that this will change.
Re: (Score:2)
Re: (Score:2)
a Start menu, didn't Microsoft remove that for security reasons?