23-Year-Old X11 Server Security Vulnerability Discovered

An anonymous reader writes "The recent report of X11/X.Org security in bad shape rings more truth today. The X.Org Foundation announced today that they've found a X11 security issue that dates back to 1991. The issue is a possible stack buffer overflow that could lead to privilege escalation to root and affects all versions of the X Server back to X11R5. After the vulnerability being in the code-base for 23 years, it was finally uncovered via the automated cppcheck static analysis utility." There's a scanf used when loading BDF fonts that can overflow using a carefully crafted font. Watch out for those obsolete early-90s bitmap fonts.

Comments

Dangerous function

[jones_supa]

There's a scanf used when loading BDF fonts that can overflow using a carefully crafted font. Watch out for those obsolete early-90s bitmap fonts.

And watch out for scanf(). There's a reason Microsoft brought scanf_s() and others, which the official C11 standard adopted later too.

Re:Privilege escalation is to the server credentia

[10101001 10101001]

Did you actually even bother checking this? No, most modern X11 servers run as root so they can* have hardware access to GLX and DRM. But, please tell me, which distro or OS do you run that runs your X11 server as non-root? Because I'd love to use a system like that.

*Technically, privilege separation is quite possible on these points, which has been done in OpenBSD AFAIK, but very few people use OpenBSD and I think the whole point of your post was about what the vast majority of people use. Otherwise, you're just quibbling over the point without stating it that most people don't run a "modern" X11 server.

Re:The usual clueless submission...

[peppepz]

Those fonts are read by fontconfig and freetype, while the bug is in the server-side font support, the one where you must run mkfontdir and possibly edit Xorg.conf to install new fonts. I don't think any distribution allows non-root users to do that.

Re:Many eyes...

[garyebickford]

Actually it was shown back in the late 1970s that it is essentially impossible for 'black box' testing to discover more than about 30% of the bugs in a sufficiently large code base. It's based on the NP-complete problem of following all possible variations of the branches using all possible combinations of input, both valid and invalid. It's fairly easy to build a one page program that can not effectively be completely tested. It was also shown that, given good programming practice, roughly 70% of the bugs are built into the design (before a line of code has been written). Then, finally, a significant number/percentage of bugs are of the sort where it's a judgement call whether it's a bug or a feature.

Source: I used to run a Software Quality Assurance Workshop for my then-company, and did the research. A few programming practices have changed, and the repertoire of automated tools has greatly increased in both quantity and sophistication, but average program size and the list of asynchronous externalities has ballooned by two or three orders of magnitude, so there we are.