Linux X.org Critical Security Flaw Silently Patched 259
eldavojohn writes "On June 17th, the X.org team was notified by Invisible Things Lab of a critical security flaw (PDF) that affected both x86_32 and x86_64 platforms. The flaw deals with escalated privileges of a user process that has access to the X server. The founder of ITL said of the flaw, 'The attack allows a (unpriviliged) user process that has access to the X server (so, any GUI application) to unconditionally escalate to root (but again, it doesn't take advantage of any bug in the X server!). In other words: any GUI application (think e.g. sandboxed PDF viewer), if compromised (e.g. via malicious PDF document) can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.' This has apparently been a security flaw since kernel 2.6 was released. From the article, 'On 13 August, Linus Torvalds committed an initial fix, but several patches were added afterward for various reasons. The problem has been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel.'"
Convenient (Score:5, Funny)
Re: (Score:3, Funny)
Just click the popup telling you that your PC is infected. That'll fix it.
Re: (Score:3, Interesting)
Another reason Linux is safer is that these problems get due attention when reported, but for the windows team puts effort to fix most problems, it has to be a source of embarrassment for the company.
Re:Convenient (Score:5, Insightful)
Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?
What rock have you been living under?
Re: (Score:2, Informative)
Oh god they're countless. Sure, the publicly known privilege escalations are patched now, but there are a few that were around for many many years.
The old NT login bug was there for a long time before MS fixed it.
Re: (Score:2)
I don't have that kind of time. Here's one.
http://www.microsoft.com/technet/security/Bulletin/MS10-054.mspx [microsoft.com]
Microsoft acknowledges that it affects Windows all the way back to XP SP3 but I'd bet my lunch money it affects SP1 also.
Re: (Score:2, Interesting)
Re: (Score:3, Informative)
1) http://blogs.pcmag.com/securitywatch/2010/08/unpatched_vulnerability_in_all.php [pcmag.com]
2) http://www.zdnet.com/blog/security/microsoft-warns-of-serious-unpatched-windows-7-flaw/6474 [zdnet.com]
3) http://blogs.pcmag.com/securitywatch/2010/08/unpatched_vulnerability_in_all.php [pcmag.com]
4) http://www.computerworld.com/s/article/9176944/Microsoft_warns_of_bug_in_64_bit_Windows_7?source=rss_security [computerworld.com]
5) http://isc.sans.edu/diary.html?storyid=8023 [sans.edu]
6) http://news.cnet.com/8301-1009_3-10170962-83.html [cnet.com]
7) http://www.geek.com/articles/chips/17-yea [geek.com]
Re: (Score:3, Insightful)
They patched [kernel.org] it, I don't know what you expect them to do beyond that. "Silently" just means that slashdot didn't pick up on it or something.
Also,
Are you kidding?
Re:Convenient (Score:5, Informative)
What are you on about? There a full changelog for the patched code. Do you have any idea how much changes in the linux tree each week? One bugfix is not going to make news other than from a pro-Windows news outlet attempting to make it appear there's a cover up. Try reading LKML if you're stupid enough to think there's a conspiracy going on.
Re:Convenient (Score:5, Informative)
Contrary to the headline written by an idiot, this isn't an Xorg bug. It's a kernel bug that can be exploited through Xorg.
Re: (Score:3, Informative)
Static analysis produces massive amounts of false positives that are easier to "fix" than to verify.
I believe, it would be a safe bet that there are still no actual vulnerabilities found and successfully exploited by this method -- and the actual exploitable vulnerability the article is about, was not and could not be found by such analysis.
So no, changelog is not a "gold mine" for anything, most of the time if will give you massive load of starting pointers that if/when you will find one that is a genuine
Re: (Score:3, Insightful)
Yes.... yes I do. We have seen it with the process messaging flaw.
Microsoft is a for-profit company. To make a profit, they have to control costs and increase sales. By paying people to patch vulnerabilities, they are increasing costs. This has the effect of lowering profit. On the other hand, their reputation has impact on their ability to make sales (though admittedly, not as much when you are not a monopoly). So if the flaw is well known (which in this case, became the headline of a great many news
Re: (Score:2)
So yes, if they felt that the threat to their profits is large enough they will take action... else they will not.
Yet regularly and frequently they release bugfixes for problems that are neither high profile, nor "embarrassing". Strange.
Re: (Score:3, Insightful)
Sure, fixing a bug might take a line or two of code.
But the time required to fully test it and make sure it doesn't break anything else? That's where all the real costs are. It's why Microsoft doesn't generally have a fast turnaround on Windows security fixes.
Re: (Score:3, Informative)
Also, note that this was silently patched with no announcement of the problem.
It was not "silently patched." It would be pretty hard to "silently patch" the Linux kernel, unless you could come up with some other explanation of your changes to the kernel developer. The patch was noted in the changelog like any other patch. No attempt was made to hide it.
Or did you think that the developers should have been screaming about the patch from the rooftops? This is not the first security bug to patch in this way.
Re: (Score:2)
Privilege escalation by any non-privileged GUI app you say? No they'd just say it's not a bug and that they have no intention of fixing it.
http://www.pretentiousname.com/misc/win7_uac_whitelist2.html [pretentiousname.com]
Re: (Score:2)
Interesting article. It's a shame the author hasn't updated it since Windows 7 RC1. As far as we know, some or all of the bugs it mentions have been fixed... or that none of them have been.
Re: (Score:2)
No they'd just say it's not a bug and that they have no intention of fixing it.
That's because it isn't. From that very web page:
All of this only affects the default account type and UAC level of Windows 7 (builds 7000 & 7022, but probably also the retail given Microsoft's stance so far). If you go against the defaults and run as a non-admin user or turn UAC up to the Always Prompt level, so it behaves like it did in Vista, then it is no longer possible for code-injection from unelevated processes to bypass UAC prompts.
Not to mention it requires the end user to manually run untrusted code.
At _worst_ it's a configuration issue. It's as much of a "bug" as the default timeout for sudo.
Re: (Score:2)
All bugs are the same in the kernel devs eyes. "crashes when the user touches their nose on days that end in X, and while mars is behind the sun relative to the earth" as well as "Press the 'y' key to become root" both get the same mention, a line in the kernel changelog.
Re: (Score:3, Interesting)
It's not a PDF flaw, it's a flaw in Linux kernel. The malicious PDF file was just an example for an attack vector. You know, the same way it works in Windows. No system is immune to these kind of attacks, the only reason Linux and Macs see them less is because most of the users are on Windows (especially the "stupid" or casual ones). Not even the walled gardens like iPhone, where PDF attack was used to root and jailbreak the system just recently.
You got it spot on. Although in my personal experience I've had more Linux servers compromised than Windows ones. Could be the fact that in general my Linux servers are exposing services to the internet where as my Windows servers are not. Or it could be the fact that at times questionable users (ie: customers) have had access to my Linux boxes. Oh and then there was one time my MS-DOS server was compromised (lol).
In general it's not the OS keeping you secure it's how valuable of a target you are and how
Re:Convenient (Score:4, Interesting)
Reference please? Which Linux servers? Red-hat? Debian? SELinux enabled?
Sounds like you know a lot about the subject..
This was between 1999 and 2003 when a partner and myself were running a small web hosting/shell company Mach Nine Internet Services, http://www.mach-nine.com/ [mach-nine.com] (under construction now?), http://www.lomag.net/information/news.php [lomag.net]
Always Redhat... started with 6 (which was the 2.2 kernel...) and think we ended at 7.1.
In any case this small period of time was the only time I've had Linux servers publicly available on the internet and two of three machines were rooted due to a (2.4?) kernel flaw that made it trivial to escalate privileges if you had a shell (which being a shell provider...). Since then I've had several Windows servers publicly servicing the internet but the difference is that they are for my personal use and not high profile (in relation to my old Linux servers) targets.
My statement was not one about the inherent security of one OS over the other. There is more I could have done to prevent the root attacks on the Linux machines and I don't deny that. I'm repeating myself here but my point was:
In general it's not the OS keeping you secure it's how valuable of a target you are and how vigilant you are at security.
Re: (Score:2)
Of course, plenty of other PDF readers do not, and on a number of desktop Linux distros, packages are compiled with stack and heap smashing protection enabled, so finding a PDF exploit would be pretty tough. Of course, a lot of people wind up installing Acrobat Reader on their systems despite the avail
Re: (Score:2)
**I'm missing something here. A PDF reader shouldn't let a PDF file anywhere near executable code, should it?***
Not a stupid question although it'll probably get treated as such. My understanding is that PDF is sort of an partial encapsulation of Postscript and therefore can include some kinds of executable code. Personally, I've never much cared for pdf/postscript which have always seemed to me to be a maximal grief approach to getting a document (possibly) printed ... if the stars are right and the forc
Re: (Score:2)
The PDF specification includes a lot of active content features that most linux readers don't even support.
One in particular comes to mind and that is javascript. Although javascript isn't directly executed by the host machine(it's interpreted), that makes it a really attractive attack vector.
Re: (Score:2)
Anything that can overrun a buffer or smash the stack can execute arbitrary code if you play around with your delivery package enough. Lots of code out there has stack or buffer issues. Some web browsers used to be exploitable just by overrunning the address bar's buffer, no executable code at all until the buffer overruns and you overwrite a JMP instruction to jump into part of what you wrote to the unchecked buffer.
Security is hard. It's even harder when you're not using a language or libraries that check
Re: (Score:2)
It sounds like if the PDF file can get the PDF reader to overflow the stack (possibly by triggering a bug that causes infinite recursion) then it will write over memory belonging to the X server which the X server will later jump to with root privileges.
I would think the most likely effect is the X server will crash but it seems there is already an example PDF that manages to write the correct data there to get the X server to execute something desired by the hacker, such as running a shell. This is NOT goo
Re:Convenient (Score:4, Funny)
Came here to post the same!
Came here to post something completely different! (I just like the attention)
Blame Xorg (Score:5, Interesting)
Re:Blame Xorg (Score:5, Interesting)
That should be fixed eventually. With the switch to kernel modesetting (already happening) there shouldn't be any need for X to mess directly with hardware anymore, and without that it should run just fine without root privileges.
Re: (Score:2)
Is that the only thing still running in userspace? I was under the impression that you still need device-specific drivers in the X server. Or are we finally approaching the point where the kernel exposes a framebuffer console with standard accelerated features (OpenGL, preferably), and X or any other program can simply run on top of that?
Re:Blame Xorg (Score:5, Informative)
Yep.
On Linux input devices are now moved into the kernel. The only complex thing remaining is modesetting and hardware acceleration. But they are being fixed as well.
In fact, you can run 'rootless X' on Fedora ( http://lwn.net/Articles/341033/ [lwn.net] ) and soon on Ubuntu ( https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-rootless-x [launchpad.net] ). Here 'rootless' means that the server doesn't require root privileges to work.
Re: (Score:2)
Re: (Score:2)
startx or one of the programs it calls has the SUID flag set. (Meaning that the process will run with the privileges of the executable file's owner, not the privileges of the user who executed it.)
Re: (Score:3, Informative)
Yes, it starts as root, but then it immediately drops privileges upon initialization.
Re: (Score:3, Informative)
It does nothing. No one used startx for many years by now.
Actually, quite a few people running "hacker" distros (Gentoo, Arch etc) prefer to boot into console and do startx from there when (and if) needed.
Re: (Score:2)
So for anyone else wanting to know what the hell Wayland is here is the link that I spent 20 minutes googling... http://groups.google.com/group/wayland-display-server [google.com]
How much more 'silent' was than other bugs? (Score:5, Insightful)
Do the Linux developers put a news announcement out every time there is a bug and they forgot about it this time?
Isn't it a little sensational to imply that Linus and the other people didn't want this bug to be known because they fear Linux will be characterized as buggy?
Re:How much more 'silent' was than other bugs? (Score:5, Insightful)
Re: (Score:2)
Re:How much more 'silent' was than other bugs? (Score:5, Informative)
Do the Linux developers put a news announcement out every time there is a bug
No, but all changes to the kernel are documented in the changelog. And security-related bugs are treated the same as any other bugs. They are not explicitly called out as being security related. Linus has been pretty clear on this in the past. A bug is a bug, period. The fact that it's security related is uninteresting (to him, at least).
I think that's a weird attitude but that's what we've got.
Re: (Score:2, Interesting)
I don't think it's all that weird. For example, is a bug that corrupts one's filesystem less critical than a bug that allows unauthorized access? Is a root escalation bug more important than a bug that prevents one's video card from working? They all need to be fixed, but I don't think security implications entitle such bugs to special treatment.
Re:How much more 'silent' was than other bugs? (Score:4, Insightful)
More importantly, is there a difference? Red Hat 9 had - and perhaps distros still have - this nice system where cron would, once a day, run programs dropped into a directory in /etc with root privileges. Very useful for various packages that required periodical maintenance; but if a filesystem corruption bug would allow one to link an arbitrary file to those directories...
A bug means that a system behaves in a way it shouldn't. There's always the chance that such unplanned behaviour can be used by an attacker to do nasty things. There is no difference between security critical and other bugs, there's only bugs with known exploits and bugs without. Every bug is a chink in the armor, and every kernel bug should be considered security-critical.
Re: (Score:3, Informative)
A filesystem corruption bug that allows one to link an arbitrary file somewhere would allow a much quicker root exploit than relying on cron!
I think you are thinking about extremely old bugs where cron itself could be convinced to run a program without root privledges as root (or really as the cron job). That is from about 1980 or earlier I think.
Re: (Score:3, Informative)
I assume you mean /etc/cron.daily which is still around, along with its hourly, weekly, and monthly counter-parts.
Re: (Score:2)
Re: (Score:2)
In the end, almost any bug is security related anyway. A denial of service by crashing my system is security related. A denial of service by tying up my ports is security related. Gaining unauthorized access is security related. Gaining more than authorized access is security related. Any bug more serious than a color or a pixel alignment being off in a UI is pretty much security-related, because security means the system is available to authorized, authenticated users and not to anyone else.
Re: (Score:3, Interesting)
Sure, because Legacy Media was so focussed on telling people what was important, rather than just what they wanted to... ooooh, OK! magazine have offered Linsday Lohan $1m for an exclusive - must read now!
Re: (Score:2)
Re: (Score:2)
Is this news? (Score:5, Insightful)
1. Bug found, responsible parties notified
2. Bug fixed and software updated
3. We are protected from potential future attacks. (Profit!)
Was there an actual attack? No.
Re: (Score:3, Insightful)
Re: (Score:2)
FROSTY PISS!
Re: (Score:2)
Re: (Score:2, Interesting)
Quickly? This flaw has existed for 7 years.
Re: (Score:2)
It could be there since linux 0.1, so what? all that it matters is that holes are patched when discovered or in the worst case when the first 0days exploits are detected.
Also thanks to the fact that there probably is no guy in business suit that decides when and if to disclose the vulnerability, I tend to think that this xorg problem was managed well enough.
Re: (Score:2)
Was there an actual attack? No.
Woah now junior, you don't know that.
There have been no reported attacks.
But now that its out there - it's up to people to update their kernel.
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Probably since we're not Microsoft. Really.
Who's got access to the Linux kernel's source code? Anyone. Compare that to who's got access to Windows' source code. Who can submit a patch for the Linux kernel? Again, anyone. Compare that to who can submit a patch for Windows.
So if there's an exploit in the Linux kernel, it's our fault... because the only thing holding any of us back from fixing it is our own lack of knowledge, ability, and/or time.
For those Windows exploits, however, we're left at Microsoft's m
How fancy can you get? (Score:2, Insightful)
The author who wrote this certainly didn't count SELinux as one of the "fancy" security mechanisms...
Re: (Score:2)
The attack allows even to escape from the SELinux's "sandbox -X" jail.
(From the announcement of the attack)
Re: (Score:3, Interesting)
Root in the kernel == game over (Score:3, Interesting)
I don't get this blind trust in SELinux can do what it was never intended to do. If you compromise the kernel - especially a monolithic kernel like Linux - it really is game over.
Practically every security check (and - yes - that includes SELinux extra hooks) are performed before the actual operation is performed with no kernel lock covering both. Which means that *all* of them are susceptible to concurrent access attacks.
It works like this: The malicious code invokes the syscall passing a structure, e.g. a
Re: (Score:3, Interesting)
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
{
int error = may_create(dir, dentry, NULL);
if (error)
return error;
if (!dir->i_op || !dir->i_op->mkdir)
2 Months is Acceptable? (Score:2, Insightful)
Re: (Score:2)
You're either with us or with them, eh ?
Who would have thought George W posted on Slashdot ?
Re: (Score:2)
Re: (Score:3, Insightful)
Whatever. He's calling Slashdot biased. Pot, meet kettle.
But Slashdot *is* biased, quite heavily, towards Linux and Open Source (and against anything not anti-Microsoft). Your previous post is, indeed, an excellent example of that bias.
Ad hominem (Score:5, Interesting)
Here is a novel idea: Stop misrepresenting what actually happened and stop ad hominem attacks questioning posters' motives .
Microsoft took five weeks to prepare the Ormandy patch. During that time, they made no comment - there was no transparency into whether or not it would be fixed.
They made no comments? Did you actually look or did you just assume?
Now to your claim that they "made no comments":
Hardly a "no comments" approach. If you click through those posts I think you'll find them smack full of info. And I've even excluded their communication on the preliminary "fix it" tools.
Admit it. You are biased, but not classy.
Like your misrepresentation and ad hominem demonstrate more class?
It seems to me that it is indeed interesting that this fix was 2 months in the making (responsibly disclosed). And that is only measuring the time until the kernel had been fixed. Now the distros would have to pick up on it and perform their own regression testing, prepare packages/updates etc.
GP did raise some really interesting questions. For some reason you chose to disregard them right away and go straight for the mans posting history.
Will you be publishing stats on my posting history as well. Am I a shill, too?
Open Source Workdays (Score:3, Informative)
Workdays was important because that is what was used in the responsible disclosure guidelines. Which recommends waiting 5 workdays of non-communication before taking a vulnerability public.
Responsible disclosure which Google strongly supported until one of their researchers broke it:
From Googles website (emphasis mine):
"This process of notifying a vendor before publicly releasing information is an industry standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to better protect our users by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure. Our Security team follows the same procedure when we discover and report security vulnerabilities to other companies.
Tavis Ormandy knew this. That is why he made a stupid claim that acted in his personal capacity, not as a Google researcher. Even though he used Google resources, Google colleagues and Googl
Re: (Score:2)
But, judging [slashdot.org] by [slashdot.org] your [slashdot.org] comment [slashdot.org] history [slashdot.org] you [slashdot.org] (Arainach) [slashdot.org] are a Microsoft [slashdot.org] shill [slashdot.org] and [slashdot.org] probably [slashdot.org] an employee.
Your Comments in the Past Year:
Anti-GPL w/o mentioning Microsoft: 2
Pro-Microsoft arguments: 9
Pro-Microsoft information: 1
One rant about WA-520 [google.com]: 1
Seriously? We've lowered ourselves to this level? "OMG you're familiar with a highway in t
Re: (Score:2)
Now THAT's what I call self-healing software!
Re: (Score:3, Informative)
Microsoft has thousands of programmers working full-time; Linux is maintained by volunteers, working in their spare time.
False. The majority of work on Linux is done by fulltime employees of companies like Red Hat.
Microsoft blah blah Linux blah blah Mac blah blah (Score:2)
As an internet user if I use for daily surfing without all sorts of virus and adware protection how likely am I to get garbage on it that slows it down and fouls my surfing experience? How about the likelihood of getting something truly malicious which makes things stop working altogether or worse yet steals my data? Is there such a thing as virus and adware protection which does not bog the computer down all by itself? B
Re: (Score:2)
only affects idiots (Score:2)
any implementation of an X server has been full of holes and dangers, only an idiot runs X server on a server. Learn the command line, you pussies! Run X server somewhere else!
Re: (Score:2)
only an idiot runs X server on a server.
Running the server version on a, actual server! IDIOTS!!!
There's still a hole. (Score:3, Insightful)
There's still a hole. See Xorg Large Memory Attacks, section 4. [invisiblethingslab.com] Opening a one-page gap in mapped memory at the top of the stack is a workaround, not a fix.
This looks like bad design. Someone got too cute with the MMU. The basic problem is shared memory between a privileged and a non-privileged program. [wikipedia.org] That just screams "security hole". It was put in to get a performance advantage for graphics-heavy applications on X, probably games. "MIT-SHM" shouldn't be enabled on a production server.
Re:There's still a hole. (Score:4, Insightful)
I wouldn't put X11 on a production server in the first place. Why would you?
Assuming you're not serving X11, I mean.
Re: (Score:2)
You're wrong
All systems have bugs, even MACs.
You're being naive if you think you are completely secure in your sandbox.
There will always be exploits and/or proof of concept exploits for MAC as well as Linux platforms, but are usually patched immediately without damage or fanfare.
Nothing to see here, move along .. SSDD
Re: (Score:2)
Agreed. If it was a true mac fan, that was just embarrassing (and this coming from me, a true Mac user). If it was a troll pretending to be a mac fan, it was still just embarrassing. All computers are vulnerable to exploits.
Back on topic, this PDF vulnerability reads a lot like the vulnerability exposed in iOS4 that allowed a jailbreak in the user space via a PDF exploit.
Are they related?
Re:What I suggest to people (Score:5, Funny)
You do realize that Mac is built on a FreeBSD kernel?
Macs can't be exploited. That's why people paid to get into the walled garden, it's safe in there. LA LA LA LA LA LA I CAN'T HEAR YOU.
Re: (Score:2, Offtopic)
lol
Though I wonder how I'm off-topic, considering this is about a Linux vulnerability.
Oh wait, this is /., nvm
Re:What I suggest to people (Score:5, Informative)
Actually, MacOS uses the Mach microkernel in a BSD system; some code was taken from FreeBSD -- but not the kernel.
Re: (Score:2)
Actually, MacOS uses the Mach microkernel in a BSD system; some code was taken from FreeBSD -- but not the kernel.
Really? I thought they used Darwin...?
Re:What I suggest to people (Score:5, Informative)
Darwin is their codename for what is the open source bits of MacOS X. The kernel is largely based on Mach. Since its a Microkernel, it can have "servers" for different subsystems, including BSD, which aren't really "kernel modules" in the Linux or BSD sense. A lot of the userland and C libraries are derived from FreeBSD, with some GNU stuff, and custom changes to both. They did hire a bunch of big-name FreeBSD people though, like Jordan Hubbard, which just contributes extra confusion to a confusing situation.
Re:What I suggest to people (Score:4, Interesting)
Except, of course, it isn't a microkernel. They ripped that out, first thing, made it monolithic for performance.
I'd love to see a common operating system using a microkernel. That seems to be the only way forward in a world of imperfect programmers and increasing attention towards turning every little flaw into vulnerabilities.
Re: (Score:2)
http://en.wikipedia.org/wiki/Mac_OS_X [wikipedia.org]
http://en.wikipedia.org/wiki/Mach_(kernel) [wikipedia.org]
Re: (Score:2)
From your first link: "Mac OS X is based upon the Mach kernel."
Re: (Score:2)
Parts of the OS X kernel has BSD code like the vfs layer, however it is definitely incorrect to call it a FreeBSD kernel.
Re: (Score:2)
You do realize that Mac is built on a FreeBSD kernel?
Well, more accurately it's a mach based os that presents both a BSD and a Mac OS personality. /pendant
Re: (Score:3, Funny)
pedant*
Unless you are actually a piece of jewelery.
Re: (Score:2)
Read your own .sig. Now educate yourself about the XNU kernel. (Hint: it's not BSD! Not even "built on" BSD!) Hope you love it.
Re: (Score:2)
http://en.wikipedia.org/wiki/Mach_(kernel) [wikipedia.org]
Re: (Score:2)
Because I run Windows as user SYSTEM.
To people who have no Windows familiarity (i.e. all sane people *ducks*): SYSTEM is roughly the same thing as root.
Re: (Score:2)
It reads like it was written, and approved of, by a marketing team...
Re: (Score:2)
Re: (Score:2)
Btw that flaw was just great... I was reading the new online on my iPhone and some site had an article "flaw in iPhone/iPad PDF", so I read it, and they directly linked a "website that was taking advantage of that flaw for malicious purposes", i.e. jailbreakme.com... I went right away and got my iPhone jailbroken in 2 clicks.
BEST. ARTICLE. EVER.
Re:Running X as root? (Score:4, Informative)
On a Linux system it's generally "setuid root", which means the filesystem permissions allow program can be run by any user, but there's a special flag that tells the kernel to actually give it root privileges, exactly so that it can do special hardware stuff.
You have to be very careful when writing a program designed to run with an effective ID of root, because it's one of the fastest ways to compromise a system if there's a flaw.
Newer versions of Xorg are moving to an architecture where they can be run without root privileges - there's already patches available, and it's an area of interest for a lot of people.