23-Year-Old X11 Server Security Vulnerability Discovered 213
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.
Many eyes... (Score:5, Insightful)
...looking elsewhere.
Re: (Score:3, Insightful)
The real trick of the "With enough eyes all bugs are shallow" is that the function for "enough eyes" is exponential with respect to lines of code, and open source projects don't actually hit it.
Re:Many eyes... (Score:5, Insightful)
Re: (Score:2)
Also bologna. There isn't such a thing as bug-spotting super powers. The most reliable way to detect bugs is testing, of multiple stripes, unit testing, regression testing, all the testing(and I'm a developer, so I detest QAs)
Re:Many eyes... (Score:5, Informative)
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.
Re: (Score:3)
Re:Many eyes... (Score:5, Insightful)
It should include bogus fonts with randomized data to test for crashes, data validation, and the like, yes.
Re: (Score:2)
"Many eyes" is bogus, "the right eyes" is more appropriate.
In this case "the right eyes" are robotic.
Re: (Score:3)
Re: (Score:2)
Having never been a significant C coder (I skipped that phase), I'll argue that by my observation the vast majority of problems would be eliminated if C programs were incapable of buffer overflows. This is less simple than it seems. It would require not only some language features, but library changes, and would slow things down (imperceptibly?).
There is no reason an application developer should ever encounter a segfault in a modern language. Many of today's languages are essentially immune to this proble
Re: (Score:2)
It would require not only some language features, but library changes, and would slow things down (imperceptibly?).
Having dealt with some fascinating FORTRAN code that ran perfectly under one compiler and failed with horrible segfaults under another, I can approve of languages that include bounds checking at execution time -- as long as it can be disabled when desired.
The specific example is a bit of FORTRAN that was processing input parameters from a file, parsing lines of text for colon delimited parameter/value pairs. Ran fine under one compiler (gfortran, as I recall), but died every time when compiled with PGI. T
Re: (Score:2)
Long ago I worked in a Pascal dialect (for the Perq workstation) that included several systems programming extensions. One was that ability to grab a block of memory as raw data, then work within that block to create and manipulate named variables as usual with full protection by the compiler. I don't recall the other extensions.
I still think that for the vast majority of the code in most applications, the performance impact of runtime checking is minimal. So it's feasible to isolate the very few compone
Re: (Score:2)
Re: (Score:3)
Yes. I've basically argued that C should not be used for application programming in general - device drivers, kernels, maybe some other high performance OS tasks, and the occasional small high performance functions in larger programs.
I can further argue that the extent to which even those domains need to be in a low-level language like C at present is really a testament to the limitations of compilers - IMHO it is high time to apply AI and machine learning techniques to compiler design and code translation
Re: (Score:3)
Many eyes does work, so much in that it helps a bit, same with static analysis it helps but not perfect and just because you have run your tool over your code does not mean you are safe.
FLOSS give you the following:
1. an independent programmer may have looked at it.
2. nobody can pull the plug.
3. If it doesn't do what you want you can add it. My favorite.
4. When a bug does occur they don't generally try to hide the fact.
FLOSS is no way a guarantee of adequate code, any idiot can write start a project, but fr
Re: (Score:2)
All you said is that sometimes we don't have enough eyes on the code. You failed to substatiate your thesis that "many eyes" is a myth. This particular bug was discovered precisely because we got some new eyes looking at the code, buffed up with a dose of technological superpower. The X11 project has traditionally been a rather small project with significant barriers to entry like cvs commit access owned jealously by a small club. It's somewhat better after being pried loose from Open Group's stultifying do
Re: (Score:3)
"no project don't actually hit it"
I think I've found a bug in your perlscript.
Re:Many eyes... (Score:5, Funny)
With enough Perl, all eyes are bleeding.
Re:Many eyes... (Score:5, Funny)
Let's see if that's true:
print "$#_ [@_]\n\n";
GAAAAAAAHHHHH!!!!!
OK, point taken.
Re: (Score:2)
won't be able to tell you where the security bugs are.
They're laying maggots in the poo that was flung at screen.
Re: (Score:2)
Not only that - some software just isn't all that racy to begin with. X11 is not really the kind of code I'd find exciting to muck with...
Re: (Score:2)
Just because a lot of people use the compiled product, doesn't mean a lot of people read the source code. One of the X developers had a presentation slide that read "three people on this earth understand X input", followed by a slide "really wish I wasn't one of them" (video [youtube.com]).
It does really help though to have multiple developers prod at your code. Compiling it with different compilers and for different CPUs and operating systems will unearth bugs. Using it in different scenarios will trigger bugs. Running
Re:Many eyes... (Score:5, Insightful)
Re: (Score:2)
Windows source code
Ow! My sides!
Re: (Score:2)
It'd be interesting to compare the source for Linux and the NT kernel.
Bureaucracy vs. a very irritable Finn.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Well the fact that you would have had to install this old outdated style font in order to trigger this.. Yes it is still secure. It can be used once you have a user login compromised, but windows is a freaking open book once that threshold is crossed.
Re: (Score:3)
Is this still true? IANA windows person, but I was under the impression that the newer versions of the OS had more and better compartmentalism and enforcement of user space.
Re: (Score:2)
Once you gain actual access the game is over. IF you have a Domain controller and have some real restrictions in place, then things get a bit harder for the attacker with a compromised login. But the added security only really comes from the PDC and the domain environment. Local security hive is still pretty easy (for an attacker) to circumvent when you have direct user access.
scary (Score:2)
Re: (Score:3, Insightful)
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.
Re:scary (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
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/2127 [slashdot.org]
Re:scary (Score:5, Insightful)
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.
Re: (Score:2)
We don't know who found the bug. If it was someone from the development team then this is equivalent to a closed source situation. Not an argument for open = better.
Re: (Score:2)
Also automated systems will find _different_ types of bugs than humans. Just like computer chess players use different strategies than human players. I anticipate that the next step will be automated systems for learning new automated bug-finding methods that humans may never have considered.
Re: (Score:2)
Amazing that when they run this kind of automated tool on a project of this importance and breadth, this is ... the only vulnerability it found?
This doesn't invalidate "many eyes" at all (as some are claiming here) -- the fact that a bunch of reviewers didn't find this one bug is unfortunate, but if "many eyes" had really failed, I would have expected automation to find dozens or hundreds of bugs.
The usual clueless submission... (Score:3, Interesting)
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....
Re:The usual clueless submission... (Score:5, Interesting)
Re: (Score:2)
I'd hope that modern compilers should catch that. gcc would have, for quite a while now. Maybe a decade?
Re: (Score:2)
You don't have to. Anyone with a writeable ${HOME}/.fonts can.
This could be really big.
Re:The usual clueless submission... (Score:5, Informative)
Re: (Score:2)
> When was the last time you installed a "specially crafted" bdf font from anywhere?
I got a very nice BDF font recently from a guy who said he can't say where he works or doesn't work. It installed very nicely, and it is signed "specially crafted" indeed! Font file also has a "Made by ANToN of eSsAy" attribution. Nice handle!
Re: (Score:2)
Re: (Score:2)
Last week I installed the custom BDF font contained in my HP 1670D logic analyzer which is needed to support a remote client display. There are people that still rely on the "obsolete" facilities of X11.
Dangerous function (Score:5, Informative)
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 [microsoft.com], which the official C11 standard adopted later too.
Re: (Score:3)
The scanf() suit of functions are pretty horrid regardless of security issues. They never do quite what you expect and have endless little quirks that frankly are just a PITA. 99% of the time its a lot easier to roll your own parsing code than get *scanf() kicking and screaming to do what you want , and with C++ you have streams anyway. Its a pity they weren't just put of their (our?) misery years ago and dumped from the C standard altogether.
Perhaps it's just that I'm ignorant... (Score:2)
Re: (Score:2)
In 1991, buffer overflows were just becoming to be an issue when it came to security. Back then, a lot of X servers came with no security, so any client could attach to the screen (no xhost or MIT magic cookie authentication.) Back then, the goal was to get functionality working in the first place. If you wanted a word processor, you had vi in an xterm, or fire up Xemacs. The only word processor would have probably been a variant of Wordperfect or possibly FrameMaker, and those were mainly living on the
Re: (Score:2)
The short answer is that carelessly written code anywhere in the system can create a vulnerability. A font needs to be loaded into memory, and in this case the code that loads it makes it possible to stick portions of the font into a part of memory where it doesn't belong. So if the "font" is actually a set of data constructed by the attacker, it can include an executable program that runs when the font is loaded.
Back in 1991, the idea that someone would ever want to do this did not enter the imagination of
Re: (Score:2)
You allocate 100 bytes on the stack for a string.
The file you are reading a string from contains a string with more than 100 bytes of text before it's closing "NULL" (\0) character. The program reads in the 100 bytes and then, because the programmer didn't tell it to check or to stop (in this instance), it keeps going.
This puts whatever is in the file into whatever is NEXT TO the place you were storing the string. Often this is harmless data that happens to be near the string but, because of the nature of
Re: (Score:3)
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 er
Re: (Score:2)
class show_me_the_money
{
private:
char string_read_from_user_input[8];
public:
virtual uint64_t money_func(int show_me);
};
Re: (Score:2)
In a letter: C.
It's a language that works very close to the metal. That allows programers to squeeze the most out of the hardware - which matters now, and mattered a lot more 23 years ago. It's fast, it's lean, it'll let you run a fast-paced 3D(ish) FPS like Doom on a 486* with fifty monsters lobbing fireballs at the player. The down-side to this is that it's very easy for a programmer to screw up - you need to be aware of exactly how everything fits together in memory and always be thinking about exception
Re: (Score:2)
I don't think it's the problem with the language proper, just with the hopeless standard C library. Nobody is forced to use it naked, though. Either roll your own wrapper, or use something already made like Dave Hanson's code from C Interfaces and Implementations [google.com].
Re: (Score:2)
Any time you load some file format there is a risk of unexpected behavior happening due to buffer overflows. I guess that it's ultimately the von Neumann architecture computer that we can blame (mixing code and data on adjacent memory areas). That, and using unsafe C functions...
Even still, we should be able to do better. I agree that it's extremely cringe-worthy that a simple font can compromise the security of the system.
Re: (Score:2)
Buffer overflow. [wikipedia.org]
Re: (Score:2)
That's alright - it won't be easy to understand if you're not a coder. In fact many coders won't understand it - unless you've done quite a lot of system level C code or possibly assembly language, many categories of these exploits will look a bit like black magic.
But in short, many categories of what should be pure data being used to exploit a security hole are things like buffer overflow exploits. A system level program written in C allocates some memory for a purpose, and due to a bad or missing length c
Re: (Score:2)
Now, why would it be even possible for an aerial flaw to allow your car to be stolen?
Re: (Score:2)
Quick guide to binary files. Mostly from my and others work on game saves.
Almost all of them store the size of an array right before the data. This is even true for things like null terminated strings. What gets fun is when you have an array of structs, which then holds an array. Most of those are read in using standard for loops, but an off by one error is still possible. Another (admittedly stupid) possibility is using a string read function that looks for the '\0' character while working with a fixe
Re: (Score:2)
In generic technical terms...
Program flow is controlled by instrumentation data on what is called the "stack". The stack grows up or down; up-growing stack attacks are somewhat more esoteric, but very doable. Down-growing stacks are readily-understood, which has lead to many people blaming the direction of stack growth on x86 for its vulnerability to these attacks (they're wrong). We'll use down-growing stacks for our explanation here.
Each function sets up, from right to left (high address to low),
Re: (Score:2)
You might also find this article interesting.
http://hackademix.net/2010/03/24/why-noscript-blocks-web-fonts/ [hackademix.net]
Personally, I find stuff like web fonts a bit more worrying since the content is served remotely, unlike installing this font, which you'd need root to do in the first place.
Re: (Score:2)
Well, the first thing you should understand is that "code" and "data" are entirely human distinctions, for a computer they're all zeros and ones. Computers have an instruction pointer which points to the memory address of the next instruction it's going to perform. If an attacker can replace the contents of that memory location, it ceases control of the system. Let's take a very basic example:
Program:
1. Load file into memory from $base to $base + $size
2. Read $offset from file
3. Read $value from file
4. Writ
Re: (Score:2)
Well, the first thing you should understand is that "code" and "data" are entirely human distinctions, for a computer they're all zeros and ones.
Some computers do understand such a distinction at the hardware level. They are slightly more hassle, so we mostly don't use that kind of functionality. That is looking like a mistake.
Re: (Score:2)
Of course, the Harvard architecture has some issues, like not being able to store code on the same device as data, which make it impractical for normal use. And mitigating those issues recreates the possibility of the security holes that Von-Neumann machines have.
Re: (Score:2)
You can craft your data (it doesn't have to be a font, well, in this specific case it does, but the technique in general doesn't care what format) so that the function loading data will keep loading data past the end of the chunk of memory it allocated for that data. And if you keep on going, you start overwriting other bits of data, such as the address where code execution should resume once the loader function finishes. Now you just replace that address with one pointing to your "data", and make your data
Qubes OS unlikely to be affected (Score:2)
It was designed assuming X11 (and Linux itself) had big security holes to begin with. [qubes-os.org]
In fact, after acclimating to the Qubes desktop architecture the whole monolithic kernel + X server arrangement looks like a raft full of holes waiting to exploited. Both the X11 layer *and* the Linux kernel need to be demoted to providing features only, not relied upon for overall system security.
Re: (Score:2)
Basically Qubes OS is as likely to be affected as a modern linux distribution. Xorg does not run with special privilege and thus the scope of the attack is things for said user.
While that means the underlying integrity of the system and other users is intact, it does little to comfort the vast majority of desktop users, as xkcd succinctly expresses: http://xkcd.com/1200/ [xkcd.com]
Re: (Score:3)
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.
My point being... (Score:2)
Through exploiting Xorg then it can likely exploit more *important* things like credit card numbers, bank account information, and so on and so forth. The likelihood is very high that the exploited X server is going to host an input of some great importance.
If the user is very fastidious in sorting every single little thing into distinct AppVMs, then the attack surface can be meaningfully reduced. However such a fastidious user is unlikely to do activities that would cause bitmap fonts to be read in from
Let's see how the "dead" NetBSD handles this... (Score:2)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NetBSD Security Advisory 2014-001
Topic: Stack buffer overflow in libXfont
Version: NetBSD-current: source prior to Tue 7th, 2014
NetBSD 6.1: affected
NetBSD 6.0 - 6.0.2: affected
NetBSD 5.1 - 5.1.2: affected
Go ahead, just TRY a buffer overflow on my VAX (Score:5, Funny)
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.
Re:Go ahead, just TRY a buffer overflow on my VAX (Score:4, Funny)
I'm tempted but the carbon footprint of the resulting 0wnage would probably be too great.
Re:Go ahead, just TRY a buffer overflow on my VAX (Score:4, Funny)
Just buy some carbon credits and you'll be back in the green.
Re: (Score:2)
I learned it decades ago. There must be near hundreds of thousands of others that also know it. That's can be a problem with a once-popular architecture like VAX.
Discovered... (Score:2)
Exploitable UIs (Score:2)
Re: (Score:2)
Re: (Score:2)
My XServers run on Windows (Score:2)
Re:Privilege escalation is to the server credentia (Score:5, Insightful)
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).
Re: (Score:2)
Re:Privilege escalation is to the server credentia (Score:5, Informative)
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: (Score:2)
Does that matter? With code pages marked as read-only and data pages marked as no execute is it even possible to turn such a buffer overflow into an exploit other than DoS any more?
Re: (Score:2)
Does that matter? With code pages marked as read-only and data pages marked as no execute is it even possible to turn such a buffer overflow into an exploit other than DoS any more?
Yes it is. The technique is referred to as "return oriented programming". That is why you need strong ASLR to make DEP/NX effective. Windows and OS X (IIRC) are the only OSes with strong and complete ASLR.
Re: (Score:2)
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.
It's possible on almost any Linux distribution if you're using a KMS-based (modern open-source) driver. Actually has been like that for a couple years now. There are some lingering permissions problems (need write access to the tty it's running on, a few other device nodes, and the log files -- most of these are solved by using SGID to a dedicated group rather than SUID to root, the rest require minor patches or config changes) but the big hurdles are gone.
It's not the default anywhere because it's mildly f
Re: (Score:2)
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.
I think you and I have different definitions of "modern": XQuartz, OpenBSD, KMS all perform privilege separation.
It's actually trivial to do privilege separation of FreeBSD and NetBSD as well, if you are willing to apply patches, but there are known bugs in their non-POSIX saved IDs implementations that are problematic in this case. Linux has similar credentials implementation problems surrounding supplementary groups.
In terms of tty ownership, there are POSIX calls which can be used to take and drop owner
Re:Privilege escalation is to the server credentia (Score:4, Informative)
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.
Re:Privilege escalation is to the server credentia (Score:4, Informative)
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:~$
Re:Privilege escalation is to the server credentia (Score:4, Informative)
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
Re: (Score:2)
> Modern X11 is never run as root
On Arch, at least, X is still run as root. I don't know about other distributions, but I would guess it is quite common. Also, because most of us like to actually use graphics for games and stuff, we run binary drivers. Can nVidia's drivers and Catalyst run with a non-root X? Neither supports KMS, so it seems the answer would be no.
Re: (Score:2)
I'm under the impression that with KMS the display-side of X no longer needs root, but that there's something about input handling that still does. As you say, non-KMS drivers would still need root.
I would expect that privilege separation could be used here, a small root stub to do the root-only things, and the rest of the server running with dropped privileges. In that situation, could the server even run as "nobody"? After all, content comes through the socket.
Re: (Score:2)
Re: (Score:2)
Any truly epic pwnage these days chains together a string of vulnerabilities like this that aren't earth shattering on their own.
Re: (Score:2)
Its how the user communicates with and controls the system, so in a sense it doesn't matter if X is 'unprivileged'.
Re: (Score:2)
I don't know why it matters to you, but no, terminology didn't change. The X server is what does the actual displaying, X clients are GUI-programs [which need not run on the same host]