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

[YoungManKlaus]

Mandatory 30c3 reference

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

[mrugiero]

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.

[A Laggy Grunt]

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.

[alanc]

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

[alanc]

Something nice to watch
https://www.youtube.com/watch?v=2l7ixRE3OCw

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.

[alanc]

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.

[alanc]

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.

[Ibidem]

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.

[alanc]

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.

[Ibidem]

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