Announcement

Collapse
No announcement yet.

Another X.Org Security Bug Found, Dates Back To 1991

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

  • #21
    Mandatory 30c3 reference

    maybe they should try this: http://www.youtube.com/watch?v=2ybcByjNlq8

    Comment


    • #22
      Originally posted by YoungManKlaus View Post
      maybe they should try this: http://www.youtube.com/watch?v=2ybcByjNlq8
      If I understand this correctly, this is just a build time "solution". It's better than using a VM based language if you only need memory safety (supposedly, I can't really say as I haven't worked with such languages), but still, this has nothing to do with actually fixing those bugs.

      Comment


      • #23
        Maybe one of those hundreds of bugs has something to do with why AMD can't fix that annoying xscreensaver crash-the one where X freezes as soon as you move the mouse.

        Comment


        • #24
          Originally posted by uid313 View Post
          Someone need to set up an automated infrastructure to run static analysis tools (such as cppcheck, pylint, phpcs, etc) on the whole Debian/Fedora source package tree.
          The cppcheck developers are doing that on the Debian package sources now.

          Announcement: https://sourceforge.net/p/cppcheck/n.../cppcheck-163/
          Scan results: http://cppcheck.sourceforge.net/devi...ort/daca2.html

          Comment


          • #25
            Originally posted by sobkas View Post
            That's so last week: http://www.phoronix.com/scan.php?pag...tem&px=MTU1NzA - Michael even included a link to that story in this one to remind you.

            Comment


            • #26
              Originally posted by hajj_3 View Post
              Whoever this guy is that has found hundreds of bugs needs to be hired fulltime to patch all of these bugs.
              He's already got a fulltime job finding bugs, as the Director of Penetration Testing for IOActive.

              Comment


              • #27
                Originally posted by Daktyl198 View Post
                but this is the X server we're talking about here. We've got to keep EVERYTHING and we've got to keep it UNTOUCHED in case something we do accidentally breaks the behavior in a super out-of-the-way corner case.
                Right, the way XAA was kept forever to avoid breaking the handful of people running on decade old cards with no one who cares enough to update/maintain their driver. Oh wait, sorry, that's a different ?flame the X developers? thread on Phoronix.

                X.Org removes functionality when it's appropriate, but a one line fix is a far more acceptable change for distros to take in as a security patch to existing releases than ripping out code people may be using. I hope we can drop this BDF code in the future and replace it with calls to the FreeType code; but as part of a normal development cycle, where there's time to test that everything that linked to it is working without it, and it can be reviewed publicly, and adopted by distros in their dev cycles, not as a urgent security fix reviewed in private by just the security team with no chance for anyone else to know it's coming.

                Comment


                • #28
                  I'm the guy who ends up backporting CVE fixes from X.org to "tinyX", which is a little project (based on a modified xorg-server 1.2.??) used for some of the smallest Puppy-related graphical live cds.
                  So I've got a few observations:
                  -A lot more of the code is unchanged than I would have expected.
                  -This means that backporting fixes is frequently trivial.
                  -On the other hand, when I read it I'm not surprised by the number of bugs or the static nature of the code. It seems to be most fun when you have a little bit of a masochistic streak...
                  -Despite the reputation X has, it's fairly quick to backport all the fixes.
                  In at least one case, the bug had once been one branch of an #ifdef that had since been deleted; the fix was to replace it with the other branch.

                  Now, since alanc mentioned FreeType:
                  Year before last, they had CVE-2012-1126 through CVE-2012-1144, and CVE-2012-5668 through CVE-2012-5670.
                  That's 22 CVEs in one year.
                  And they had a number in 2010 and 2011.
                  So I'm not sure if replacing libXfont with FreeType would be a gain.

                  Comment


                  • #29
                    Originally posted by Ibidem View Post
                    Now, since alanc mentioned FreeType:
                    Year before last, they had CVE-2012-1126 through CVE-2012-1144, and CVE-2012-5668 through CVE-2012-5670.
                    That's 22 CVEs in one year.
                    And they had a number in 2010 and 2011.
                    So I'm not sure if replacing libXfont with FreeType would be a gain.
                    libXfont already uses FreeType to render OpenType, TrueType, and PostScript fonts, so using it for another font type isn't going to be much of a change either.

                    Comment


                    • #30
                      Originally posted by alanc View Post
                      libXfont already uses FreeType to render OpenType, TrueType, and PostScript fonts, so using it for another font type isn't going to be much of a change either.
                      Ah, thanks. The version I'm dealing with has FreeType disabled (fontfile/ffcheck.c and fontfile/register.c have references to it, but it isn't turned on).

                      Comment

                      Working...
                      X