Announcement

Collapse
No announcement yet.

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

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

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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • alanc
    replied
    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

    Leave a comment:


  • A Laggy Grunt
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • YoungManKlaus
    replied
    Mandatory 30c3 reference

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

    Leave a comment:

Working...
X