Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security Bug Graphics Unix X Linux

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.
This discussion has been archived. No new comments can be posted.

Just-Announced X.Org Security Flaws Affect Code Dating Back To 1987

Comments Filter:
  • Wha?!?!!! (Score:5, Funny)

    by Anonymous Coward on Tuesday December 09, 2014 @02:10PM (#48556967)
    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!
    • by Anonymous Coward on Tuesday December 09, 2014 @02:15PM (#48557019)

      Because Xorg is beautifully programmed and easy to understand so any programmer can quickly contribute to it's code.

      • Re:Wha?!?!!! (Score:5, Insightful)

        by Rei ( 128717 ) on Tuesday December 09, 2014 @03:09PM (#48557559) Homepage

        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.

        • 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.

        • 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, Insightful)

      by phantomfive ( 622387 ) on Tuesday December 09, 2014 @02:19PM (#48557055) Journal

      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.

      • by Anonymous Coward

        To be blunt, the vulnerabilities were only disclosed so the finders could collect the bounty.

      • Re: (Score:3, Interesting)

        by ArcadeMan ( 2766669 )

        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)

          by ruir ( 2709173 )
          LOL. Windows not reusing code? I guess you believe in santa claus and the fairy tooth too.
          • by Alomex ( 148003 )

            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.

            • by ruir ( 2709173 )
              So you are saying they are masochists that write everything from scratch, and automagically the binaries are eerily compatible between versions. And I quite remember not long ago they discovering a 20 year old bug - but hey, I could be wrong saying they reuse code and I do not believe their markeing. http://www.techradar.com/news/... [techradar.com]
        • Re:Wha?!?!!! (Score:5, Informative)

          by king neckbeard ( 1801738 ) on Tuesday December 09, 2014 @02:45PM (#48557307)
          They apparently use code that's two decades old, as this bug [newstalkzb.co.nz] was only recently fixed
        • by Anonymous Coward

          "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.

        • by Anonymous Coward

          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

          • Yeah, but OS-X doesn't use X, never did. NEXTSTEP, its ancestor, used Display PostScript, and OS-X uses something called Quartz. Neither of which has anything remotely to do w/ X11.
        • 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.

          • 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.

            • 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.

              • 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.

                • 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)

                    by phantomfive ( 622387 ) on Tuesday December 09, 2014 @05:52PM (#48559077) Journal

                    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.

                    • 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.

                    • 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

                    • 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.

                    • 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

                    • It was stupid for them to lock processor-dependent stuff into the API and it means you get these ridiculous anachronisms.

                      So true.

                    • 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.

                • P.S.: I think the use of the word "WORD" makes things confusing in the first place.

          • 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)

          by phantomfive ( 622387 ) on Tuesday December 09, 2014 @03:13PM (#48557595) Journal

          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.

        • 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.

          • 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]

            • 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].

          • 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.

        • by dabadab ( 126782 )

          Windows 95 is long gone from modern Windows version.

          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

          • by Zappy ( 7013 )

            Windows NT has a lineage dating back to April 1987 with the release of OS/2 1.0

        • by Scoth ( 879800 )

          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

          • 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...

            • by Scoth ( 879800 )

              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.

      • by OzPeter ( 195038 )

        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, Interesting)

        by Anonymous Coward

        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

        • From your own link, "there weren't any eyeballs."
        • 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

        • 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 idealistic as it operates under the pretence that everyone has as much insight and knowledge into the software as the author(s) have, focusing solely on the quantity of eyes.

          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

          • by grcumb ( 781340 )

            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 idealistic as it operates under the pretence that everyone has as much insight and knowledge into the software as the author(s) have, focusing solely on the quantity of eyes.

            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

    • That's why most respectable Linux administrators don't run X on servers. Most of us just turn off that pesky GUI so that we can get work done.

      I don't suppose M$ has some kind of command-line mode for their servers? Some sort of Disk Operating System which could be used to provide a runtime environment for applications and services without requiring the use of a large, resource-hogging graphical interface which (as has been pointed out) is a great place to find exploitable code.

      It's proprietary code! Su

      • by lgw ( 121541 ) on Tuesday December 09, 2014 @03:40PM (#48557861) Journal

        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).

    • You don't get it. We've forked it 5 times; it's just old, bad code. We need to rewrite a completely new X system like Wayland or Mir so that all these old bugs are permanently gone.
      • by Uecker ( 1842596 )

        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

    • by 0123456 ( 636235 )

      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?'

  • by Anonymous Coward on Tuesday December 09, 2014 @02:18PM (#48557047)

    Open Source does not guarantee that all of the bugs will be found, it merely guarantees that all of the bugs can be found.

    • 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?)

  • One of the big claims is because you can't look at closed source code, bugs go undetected for longer.... 1987?

    • by Etzos ( 3726819 )
      While many people seem to say that, I don't believe that's the actual claim. I think the claim is that it's easier to find bugs in free/open source software because the code can be read by everyone. That is, it's more likely that if there is a bug it will be found and fixed. While that may imply, to a certain degree, that bugs can go undetected for longer in closed source software it certainly doesn't state it outright. And in large code bases like X.org it's hard to imagine that old pieces of code that hav
    • by jellomizer ( 103300 ) on Tuesday December 09, 2014 @02:42PM (#48557259)

      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.

    • The manner in which you state it seems far more common in strawman arguments than the actual arguments being made. Most claims regarding FOSS security are rooted in averages in situations with all other factors being roughly equal.
  • Or is that project even still around?

    • by halivar ( 535827 )

      Wow. Nevermind. It died in 2008. Y'all, I'm old and time slips by me pretty quick. Sorry.

    • 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.

    • X.org started from a fork of XFree86, so it wouldn't make any difference.

  • by Uecker ( 1842596 ) on Tuesday December 09, 2014 @02:31PM (#48557151)

    Original story:
    http://it.slashdot.org/story/1... [slashdot.org]
    CCC talk:
    http://media.ccc.de/browse/con... [media.ccc.de]

  • 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....).

    • by sjames ( 1099 )

      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.

      • by hansot ( 2960597 )

        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

        • by armanox ( 826486 )

          Mind if I ask which porting project you were a part of? There used to be quite a bit of X11 implementations.

  • Just to clarify, if we use X10 we're good?

  • News at 11!!! (Score:5, Informative)

    by sl3xd ( 111641 ) on Tuesday December 09, 2014 @03:46PM (#48557913) Journal

    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.

  • I hope this isn't going to happen every 24 years.

    Just tell me that Motif is still safe.

  • Ubuntu would fix the X.org problems in their latest version. Nothing like the GUI locking up and then going into a command prompt and seeing xorg sucking up all the system resources.

Somebody ought to cross ball point pens with coat hangers so that the pens will multiply instead of disappear.

Working...