Slashdot Mirror
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.
...looking elsewhere.
When was the last time you installed a "specially crafted" bdf font from anywhere?
There are *much* worse actual security problems than this one, which in practice, wasn't much of a problem in its day several decades ago, and isn't a problem now...
What's good is that the tools keep improving, and exposing problems...
I sure wish Slashdot's editors would actually apply their brains to submissions, rather than cluttering up slashdot with things that aren't important; there will be security reports that actually matter for people to pay attention to....
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.
Root isn't the only kind of vulnerability. Seizing control of peoples' UIs is a pretty big deal(especially as far as phishing or keylogging goes).
Given that you need to be using obsolete 90s bitmap fonts for this to be an issue, and that X11/X.org is never run as root, I'm not sure that "scary" is the word for this (there's a reason it hasn't come up before in the 23 years since it was introduced).
Nonetheless, I'll be upgrading my X.org package just for thoroughness.
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.
Eurohacker European paranoia, gun rights, and h
My Debian unstable installation would beg to differ.
$ ps aux /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-86aX4a
[...]
root 24768 6.1 0.4 183832 34716 tty7 Ss+ Jan08 14:15
Not amazed at all. Tools are much better at detecting these kinds of bugs than humans, with out limited stack space. And as time goes on, we build better tools. I'm not really surprised at all that humans aren't spending their time poring over the intricacies of an old font loading section.
Especially not surprised that people aren't looking for local privileged escalation vulnerabilities.
Also not surprised as X's security model has been known to be flawed for years.
http://it.slashdot.org/story/13/12/31/2127243/x11xorg-security-in-bad-shape
Well.. maybe. Or Maybe not. But Definitely not sort of.
Given that you need to be using obsolete 90s bitmap fonts for this to be an issue, and that X11/X.org is never run as root, I'm not sure that "scary" is the word for this (there's a reason it hasn't come up before in the 23 years since it was introduced).
Correct in principle, except for two remarks:
So yes, not "scary". Just a critical security bug.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
I'm running OpenBSD on my VAX. Go ahead. Try to exploit a buffer overflow on my home VAX cluster. If you can, then you deserve a prize because you've learned VAX machine code.
Karma: Excellent. 15 moderator points expire sometime.
Right. And this is why its so important to have the source code available. Some argue, "Who actually looks at this stuff?" Well, here's an example of someone who did. Not in the classical sense of some aspie code geek reading it by hand. But just feed it to some automated tools and see what pops out.
Have gnu, will travel.
Did you actually bother to check on multiple platforms? It's only on FreeBSD that the X server runs on root
drink@alexander:~$ cat
Ubuntu 13.10 \n \l
drink@alexander:~$ ps auxw | grep X /usr/bin/X -core :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
root 1267 2.3 1.1 348276 96612 tty7 Ss+ Jan05 105:36
hmm.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
And I've long seen that as a stupid design- mixing addresses and data in the same stack. You don't have to do that.
It's funny how Intel/AMD make CPUs with billions of transistors and yet we are still mixing data and program addresses on the same stack.
If you have separate stacks for parameters/data and return addresses, the attacker could clobber other data with data, but the program would still be running its intended code instead of arbitrary code of the attacker's choice - so it's more likely to throw errors or crash rather than get trivially pwned.
Keeping separate stacks might even help with CPU performance - when you know that one stack always contains return addresses it could be easier to do optimization tricks - prefetching, cache prioritizing etc.
Of course you will still be able to exploit certain programs by overflowing and overwriting other parameters - for example a program ends up seeing "OK" in a parameter instead of "NO" and so it does something differently. But hackers won't be able the other common stuff they do nowadays.
Incorrect. An exploited Qubes X11 has control over only the apps and data assigned to the exploited Xen domain; it would remain blocked from any baremetal administrative functions.
An exploited baremetal Linux/X11 has control over user I/O for everything done by the exploited user, so they are SOL as soon as they try to perform a system-wide admin function.
Keeping sensitive data under different user accounts would provide virtually no protection for threat models that apply to typical desktops.
Really? A quick look at Solaris11, Scientific Linux, and Fedora all say root. If I had my IRIX box up and running I'd bet it would say root too (granted, it's XSGI, not XOrg, so this probably doesn't apply). My HP-UX and AIX boxes don't appear to be running any form of X
From SL 6.4: /etc/issue
[armanox@dionysus ~]$ cat
Scientific Linux release 6.4 (Carbon)
Kernel \r on an \m
[armanox@dionysus ~]$ ps auxw | grep X /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-Ms7KTS/database -nolisten tcp vt1 /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-Ms7KTS/database -nolisten tcp vt1
root 2413 1.1 0.8 150984 34360 tty1 Ss+ 04:05 8:04
armanox 14804 0.0 0.0 103252 848 pts/2 S+ 15:52 0:00 grep X
[armanox@dionysus ~]$ ps -ef | grep X
root 2413 2410 1 04:05 tty1 00:08:04
armanox 14825 14767 0 15:53 pts/2 00:00:00 grep X
[armanox@dionysus ~]$
and Fedora 18: /etc/issue
[armanox@hecate ~]$ cat
Fedora release 18 (Spherical Cow)
Kernel \r on an \m (\l)
[armanox@hecate ~]$ ps -ef | grep X /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-nsglUa/database -seat seat0 -nolisten tcp vt1
root 596 1 0 00:13 ? 00:00:00
root 935 797 0 00:13 tty1 00:00:18
armanox 25526 1866 0 11:54 pts/1 00:00:00 grep --color=auto X
[armanox@hecate ~]$
Solaris on Sparc: /usr/bin/Xorg :0 -nolisten tcp -br -novtswitch -auth /tmp/gdm-auth-cookies-pEay
Last login: Mon Jan 6 17:28:37 2014 from lab-files-001.l
Oracle Corporation SunOS 5.11 11.0 November 2011
admin@solarisvmsrv1:~$ ps -ef | grep X
root 1308 1303 0 Nov 06 vt/7 102:15
admin 41176 41171 0 11:35:42 pts/1 0:00 grep X
admin@solarisvmsrv1:~$
I'm starting to think GNU is the problem with "GNU/Linux" these days.