Announcement

Collapse
No announcement yet.

X.Org Security Advisory For X11 Going Back To 1993

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • X.Org Security Advisory For X11 Going Back To 1993

    Phoronix: X.Org Security Advisory For X11 Going Back To 1993

    An X.Org security advisory was issued this week in regards to authenticated X clients being able to cause the X Server to use memory after it was freed. This particular use-after-free memory issue, which could lead to a system crash and memory corruption, has been present in every X11/X.Org Server release going back to September of 1993...

    http://www.phoronix.com/vr.php?view=MTQ4MjI

  • #2
    So besides crashing the system, is there any other risk here?

    Comment


    • #3
      20 years old bug.
      Nobody probably touched this code.
      It probably isn't even used on modern systems.
      Few probably knew what it was doing.

      X.org needs to burn some code with fire.
      Throw out legacy stuff that isn't needed on modern systems.

      Comment


      • #4
        Originally posted by uid313 View Post
        X.org needs to burn some code with fire.
        Throw out legacy stuff that isn't needed on modern systems.
        ... like, the entire X?

        Comment


        • #5
          Originally posted by dee. View Post
          ... like, the entire X?
          No, not DRI2, DRI3 and Xinput 2.

          But remove things like DRI1, XLFD, Xt, Xv, etc.
          There are several input extensions that do the same thing, etc.
          Remove the redundant, duplicate stuff.
          Remove the old parts that aren't used anymore.

          Comment


          • #6
            Originally posted by uid313 View Post
            20 years old bug.
            Nobody probably touched this code.
            It probably isn't even used on modern systems.
            Few probably knew what it was doing.

            X.org needs to burn some code with fire.
            Throw out legacy stuff that isn't needed on modern systems.
            The article specifically said that this bug is known to occur in every version of X11. While I'm sure the occurrence is rare (particularly due to the fact that systems have more RAM than necessary these days) and very situational, I think it's still good to knock out a bug that has been surviving an embarrassingly long time.


            I get the impression this bug wasn't very difficult to fix - gets me to wonder how many other bugs are still around that could have been fixed years ago.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              The article specifically said that this bug is known to occur in every version of X11. While I'm sure the occurrence is rare (particularly due to the fact that systems have more RAM than necessary these days) and very situational, I think it's still good to knock out a bug that has been surviving an embarrassingly long time.


              I get the impression this bug wasn't very difficult to fix - gets me to wonder how many other bugs are still around that could have been fixed years ago.
              Yeah, someone need to run AdressSanitizer, Valgrind or some static code analysis tool over the code base.

              Comment


              • #8
                Originally posted by uid313 View Post
                No, not DRI2, DRI3 and Xinput 2.

                But remove things like DRI1, XLFD, Xt, Xv, etc.
                There are several input extensions that do the same thing, etc.
                Remove the redundant, duplicate stuff.
                Remove the old parts that aren't used anymore.
                Thats a marketing problem, uid. It came up in Daniel's or Kristin's talk a year or two ago. The reason for XLFD's and 'legacy' crap like that is because when you say "I am an X11 compliant server" their attitude is you can't lie about that. So if you say "I follow X11" you HAVE TO FOLLOW X11's spec. And X11's spec says "XLFD's must be sorted. Core Rendering must be available. Fonts must be available to be handled server side." And a crap ton of other things.

                This is one of the points I tried to hit on, but that people didn't understand at the time, when I wrote The Wayland Situation last year or whenever it was I wrote that:

                Sure, we could make an X12 (the docs are already there) and rip out all of that stuff, but that creates a problem. There are people out there, beyond Xorg, who care about "X" and would want to get a say in "X12." It means we might not GET the clean slate we want / need for one or a dozen different reasons (backwards compatibility being one of them, maybe.) By going creating "Wayland" there's no emotional / mental / etc baggage of "X." Its not "X12" its not even "X" its something COMPLETELY different, its not -claiming- to be X12, its not claiming to be X, it is its own thing.

                If someone ELSE, some other company, or some other group THEN wants to come and along and create X12 as the "True" successor to "X11" and they want to go around to all the Unix vendors (for example) and say "We're making THE TRUE Successor to X11-- X12! Give us your input" And are convinced that the "X" style protocol IS the right way to do things and that the Wayland protocol is the WRONG way to do things, they can. And they can market it as "The Next Generation Of X", "X12" And whatever else they want, assuming they got the copyright from Xorg. Because WE (The Linux community) isn't in the X world anymore. We're in the Wayland world. We're doing our own thing that suits OUR needs in OUR way.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  No, not DRI2, DRI3 and Xinput 2.

                  But remove things like DRI1, XLFD, Xt, Xv, etc.
                  There are several input extensions that do the same thing, etc.
                  Remove the redundant, duplicate stuff.
                  Remove the old parts that aren't used anymore.
                  If it's not used anymore then it's not bothering anybody.

                  Comment


                  • #10
                    Originally posted by johnc View Post
                    If it's not used anymore then it's not bothering anybody.
                    That's not quite true. It's kind of like the saying "if it ain't broke, don't fix it", where that's a very naiive and impractical motive (or lack thereof) in the technology world - if there is substantial room for improvement, you might as well consider it broke. While I respect the idea that X11 intends to remain backwards compatibility, anybody who actually demands such old obsoleted technologies to be continued are a burden to both users and developers. It's getting so bad that wayland's development became a necessity. It's kind of like how a year ago when the linux kernel decided to ditch the old i386 architecture - sure there MIGHT be some people out there who still use that architecture, but what kind of i386 system can effectively handle the linux 3.x kernel, and what does the linux 3.x kernel have to offer that i386 users would want/need (assuming whatever is necessary is even physically possible)? While X11 isn't anywhere near as complicated as the linux kernel, the latter point still stands - what hardware from 15+ years ago will have any use of the modern abilities of X11? Anybody who still wants these old features could just simply use an old version of X11. I'm a huge fan of backwards compatibility, but there IS a point where convenience becomes an ever increasing burden.

                    I'm not going to pretend I know how everything works in X11 and I'm not saying that X11 unquestionably should just ditch these old features. But another point to make is if X11 intends to keep backwards compatibility, every obsoleted feature that stays with X11 becomes one more thing for developers to maintain.
                    Last edited by schmidtbag; 10-10-2013, 02:50 PM.

                    Comment


                    • #11
                      Originally posted by schmidtbag View Post
                      That's not quite true. It's kind of like the saying "if it ain't broke, don't fix it", where that's a very naiive and impractical motive (or lack thereof) in the technology world - if there is substantial room for improvement, you might as well consider it broke. While I respect the idea that X11 intends to remain backwards compatibility, anybody who actually demands such old obsoleted technologies to be continued are a burden to both users and developers. It's getting so bad that wayland's development became a necessity. It's kind of like how a year ago when the linux kernel decided to ditch the old i386 architecture - sure there MIGHT be some people out there who still use that architecture, but what kind of i386 system can effectively handle the linux 3.x kernel, and what does the linux 3.x kernel have to offer that i386 users would want/need (assuming whatever is necessary is even physically possible)? While X11 isn't anywhere near as complicated as the linux kernel, the latter point still stands - what hardware from 15+ years ago will have any use of the modern abilities of X11? Anybody who still wants these old features could just simply use an old version of X11. I'm a huge fan of backwards compatibility, but there IS a point where convenience becomes an ever increasing burden.

                      I'm not going to pretend I know how everything works in X11 and I'm not saying that X11 unquestionably should just ditch these old features. But another point to make is if X11 intends to keep backwards compatibility, every obsoleted feature that stays with X11 becomes one more thing for developers to maintain.
                      I don't disagree with you from the perspective of maintenance burden. I would just say that there is no practical impact on the side of user function. I just get the impression that sometimes people think that if all the "legacy cruft" was removed from [project X] that things would automatically perform better, use less RAM, provide a better user experience, etc. That isn't necessarily so... and typically not so at all in a mature project like Xorg.

                      Comment


                      • #12
                        Originally posted by johnc View Post
                        I don't disagree with you from the perspective of maintenance burden. I would just say that there is no practical impact on the side of user function. I just get the impression that sometimes people think that if all the "legacy cruft" was removed from [project X] that things would automatically perform better, use less RAM, provide a better user experience, etc. That isn't necessarily so... and typically not so at all in a mature project like Xorg.
                        That is true - on the user end, I'm sure there's very little to be affected by. I'm sure if ALL "legacy cruft" were removed then xorg might have a performance improvement in some way (even if just loading speeds), but I wouldn't find that significant enough. But the way legacy backward compatibility affects users is when certain technologies can't be used because it would break the legacy support, or, when workarounds must be made, which in turn negatively affects performance. So at a glance, support for 15+ year old extensions or libraries might not have any effect, but preserving their existence is a problem.

                        Think of it like AMD keeping their AM3 series alive through AM3+. If they just went with a brand new socket, a new chipset (without any intention of being backwards compatible), with triple channel memory support, the FX series of CPUs could have EASILY gained enough performance to go from "disappointing" to "adequate". FYI, I actually own an AM3+ CPU (I own an AM3 board that I've had since 2009 and wanted to get one last breath out of it).

                        Comment


                        • #13
                          Originally posted by Ericg View Post
                          Thats a marketing problem, uid. It came up in Daniel's or Kristin's talk a year or two ago. The reason for XLFD's and 'legacy' crap like that is because when you say "I am an X11 compliant server" their attitude is you can't lie about that. So if you say "I follow X11" you HAVE TO FOLLOW X11's spec. And X11's spec says "XLFD's must be sorted. Core Rendering must be available. Fonts must be available to be handled server side." And a crap ton of other things.

                          This is one of the points I tried to hit on, but that people didn't understand at the time, when I wrote The Wayland Situation last year or whenever it was I wrote that:

                          Sure, we could make an X12 (the docs are already there) and rip out all of that stuff, but that creates a problem. There are people out there, beyond Xorg, who care about "X" and would want to get a say in "X12." It means we might not GET the clean slate we want / need for one or a dozen different reasons (backwards compatibility being one of them, maybe.) By going creating "Wayland" there's no emotional / mental / etc baggage of "X." Its not "X12" its not even "X" its something COMPLETELY different, its not -claiming- to be X12, its not claiming to be X, it is its own thing.

                          If someone ELSE, some other company, or some other group THEN wants to come and along and create X12 as the "True" successor to "X11" and they want to go around to all the Unix vendors (for example) and say "We're making THE TRUE Successor to X11-- X12! Give us your input" And are convinced that the "X" style protocol IS the right way to do things and that the Wayland protocol is the WRONG way to do things, they can. And they can market it as "The Next Generation Of X", "X12" And whatever else they want, assuming they got the copyright from Xorg. Because WE (The Linux community) isn't in the X world anymore. We're in the Wayland world. We're doing our own thing that suits OUR needs in OUR way.
                          But X12 would mean a whole new protocol written from the bottom up. It would be a huge undertaking.
                          I think we should just throw out all old stuff, and be like "Ok, this is not X11" and make it a reduced subset of X11 and call it X11-Lite or something.

                          Originally posted by johnc View Post
                          If it's not used anymore then it's not bothering anybody.
                          It makes it slower to compile, harder to refactor, more prone to crashes and bugs and security vulnerabilities, and makes it more difficult for new developers to pickup X.Org and join in.

                          Comment


                          • #14
                            I think there's very little performance improvement to be had from cruft removal - CPUs are so fast now and memory so large compared to even a few years ago, that X just isn't a performance bottleneck. Cleaning it all up might save a megabyte on a livecd. Who cares.

                            That said, if X is to be continued as a display technology, there may be developer benefits to cleaning up the codebase. If X is not going to be continued a long time, it's probably best to do the minimal changes until it becomes irrelevant. There are better places to spend the effort.

                            I just worry that network transparency will be lost or made difficult to use in newer display server systems - especially with regard to LTSP as it's used here daily to make old hardware into dumb terminals into the same system. Makes things a lot simpler to administer when everything is really running on one machine.

                            Comment


                            • #15
                              Originally posted by johnc View Post
                              use less RAM
                              That's true if the feature is in the core binary. Probably not a lot less, though.

                              Comment

                              Working...
                              X