Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 31

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

  1. #21
    Join Date
    Jul 2013
    Posts
    441

    Default

    Quote Originally Posted by uid313 View Post
    Does this really have to be fixed?

    Cant that module or part just be removed?
    Is it really necessary these days?

    Does anything really make use of that functionality?
    Ahh, see, this would be the logical course of action... 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.

    It made me sad when Wayland adopted a similar approach, since we've all seen how that worked out...

    I've been thinking that a 2-release (major release, not point releases) lifespan of things you didn't actually want would be smarter.
    E.g. you put in X feature in 2.0 but almost nobody used it (leading to nobody maintaining it) and it was starting to interfere with other things, you would be forced to wait until version 4.0 until you could rip it out, but you COULD rip it out.
    Depending on the project, that 2.0 <--> 4.0 wait time could be super long or super short. On a display server, it could be a very long wait, but that just gives the complainers less to complain about.

  2. #22
    Join Date
    Aug 2011
    Posts
    82

    Default Mandatory 30c3 reference

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

  3. #23
    Join Date
    Jan 2011
    Posts
    1,287

    Default

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

  4. #24
    Join Date
    Oct 2013
    Posts
    53

    Default

    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.

  5. #25
    Join Date
    Feb 2008
    Location
    California
    Posts
    79

    Default

    Quote 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

  6. #26
    Join Date
    Feb 2008
    Location
    California
    Posts
    79

    Default

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

  7. #27
    Join Date
    Feb 2008
    Location
    California
    Posts
    79

    Default

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

  8. #28
    Join Date
    Feb 2008
    Location
    California
    Posts
    79

    Default

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

  9. #29
    Join Date
    Nov 2011
    Posts
    306

    Default

    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.

  10. #30
    Join Date
    Feb 2008
    Location
    California
    Posts
    79

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •