| |||||||||||||
Xorg flawXorg flawPosted Aug 18, 2010 23:35 UTC (Wed) by avik (guest, #704)Parent article: An ancient kernel hole is closed
Isn't there still a flaw in Xorg? With the patched kernel an X client can still trigger recursion and crash the server.
What kind of server code allows unbounded recursion to be triggered by a client?
(Log in to post comments)
Xorg flaw Posted Aug 19, 2010 0:43 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
That was my first response as well. This sounds like a stack-overflow bug in Xorg, not a kernel bug at all. Since when have guard pages been considered a robust security feature?
Xorg flaw Posted Aug 19, 2010 1:01 UTC (Thu) by airlied (subscriber, #9104) [Link]
and thats why we are thankful you aren't doing security development.
Xorg flaw Posted Aug 19, 2010 1:07 UTC (Thu) by avik (guest, #704) [Link]
In addition to being thankful, can you also be helpful and explain? With the guard page, isn't the attack transformed from an exploit to a DoS?
Sure, the guard page helps mitigate the consequences, but as far as I can see a vulnerability still exists.
Xorg flaw Posted Aug 19, 2010 1:08 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
Care to explain, instead of posting snarky remarks?
You can't exploit this without making Xorg overflow its stack. Even with the changes to the kernel that will cause Xorg to crash. Ergo, it is a bug in Xorg. It's nice that the kernel offers a way to catch stack overflows, but the responsibility lies with Xorg not to do that in the first place. This is no more a kernel security bug than an internal Xorg buffer overflow or the like, which can lead to exactly the same sort of privilege elevation.
If you're the kind to rely on guard pages for security rather than avoiding stack overflow by design, I suppose we can be glad you don't do security development.
Xorg flaw Posted Aug 19, 2010 5:35 UTC (Thu) by smurf (subscriber, #17840) [Link]
How exactly do you prevent stack overflows? Call a check_for_stack_limit() function from everywhere, which checks how big the stack is vs. how big it should be? (It would need to scan /proc/self/maps to figure out where the last shared memory segment happened to be placed.)
"The application is responsible" is a cop-out because there are zillions of programs out there, but only one kernel. Therefore, fixing the problem once (in the kernel), with a guard page (no need for expensive user-mode checks), is the right solution.
Of course, X should not recursively overrun its stack. It's (probably) still a bug in the X server. So?
"Security by forcing the programmer to write correct code" does not work. As a further example of this principle, witness the large number of PHP-based web sites with SQL injection holes.
Xorg flaw Posted Aug 19, 2010 6:20 UTC (Thu) by avik (guest, #704) [Link]
What's the algorithm that requires unbounded (or user-bounded) recursion in X? Is it impossible to write it in a way that uses an external allocation rather than the stack?
Cf. quicksort.
The kernel should provide a guard page to prevent against unknown flaws, but known flaws should be corrected.
recursion Posted Aug 19, 2010 16:33 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
AFAIU It is always possible to transform a recursive algorithm into an equivalent iterative one which stores intermediate state on the heap.
In some cases the recursive algorithm will be clearer, which makes maintenance easier (and reduces the chance of security relevant bugs). In some cases the iterative algorithm will be faster (particularly if your programming language or compiler suck)
recursion Posted Aug 22, 2010 3:31 UTC (Sun) by jeremiah (subscriber, #1221) [Link]
>AFAIU It is always possible to transform a recursive algorithm into an equivalent iterative one which stores intermediate state on the heap.<
you don't write much XSLT do you...;)
Xorg flaw Posted Aug 19, 2010 15:27 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> How exactly do you prevent stack overflows?
This is not exactly a new problem. There is plenty of software out there (e.g. real-time embedded systems; the Linux kernel itself) which manages not to crash or misbehave when faced with a fixed-size stack and no special VM protection. The tools are simple:
1. Do not permit unbounded stack recursion.
There may be "zillions" of application programs, but most of them don't run as root and simultaneously share memory with untrusted clients. As a privileged server process, Xorg should be designed to be more secure than most, since *any* code-execution vulnerability in Xorg is a (potentially remote) privilege-escalation vulnerability.
> Of course, X should not recursively overrun its stack.... So?
So it's not a kernel bug. It may be easier in this case to block one known exploit vector by changing the VM behavior of the kernel, and I'm not arguing against the patch, but it's not the kernel's job to prevent you from mapping untrusted memory right below your stack, or from overflowing said stack.
Xorg flaw Posted Aug 19, 2010 1:14 UTC (Thu) by xtifr (subscriber, #143) [Link]
If you can figure out a way to implement MIT-SHM without this flaw and without crippling performance, I'm sure the developers at Xorg would be happy to accept your patch. Note that the article specifically mentions that Xorg tried and failed to find a complete fix on their side.
Xorg flaw Posted Aug 19, 2010 1:40 UTC (Thu) by avik (guest, #704) [Link]
From what I've read it appears the recursion flaw was unrelated to MIT-SHM:
"3. Allocate windows arranged so that when X processes them, some function
Looks like any X client can crash the server, with or without a patched kernel.
Xorg flaw Posted Aug 19, 2010 3:21 UTC (Thu) by xtifr (subscriber, #143) [Link]
Fair enough, but it still says that Xorg tried and failed to find an adequate fix. If the kernel fix prevents privilege escalation, then what we're left with is merely a potentially annoying bug. Sure, it would be nice to have the bug fixed, but until someone comes up with a fix that works, it's going to be hard to fix it! (The first rule of Tautology Club is the first rule of Tautology Club.)
In any case, runaway memory use already puts your processes in the whimsical hands of the OOM-killer.
Xorg flaw Posted Aug 19, 2010 17:32 UTC (Thu) by iabervon (subscriber, #722) [Link]
I think that there are actually three things the client has to do: get the server to allocate enough server-side, non-shared resources to use up most of the address space and force the remainder somewhere useful; get a shared memory segment so that the client will be able to change an area of the server's address space; and get the server to overflow the stack into the shared memory segment.
The shared memory aspect is not really a flaw to avoid; the flaws to be fixed on the userspace side are really that the server will go overboard allocating resources for clients, rather than applying some limits to protect itself, and that the server's stack can grow into the heap. At some point, the server should refuse to do what the clients are asking in order to protect itself from overloading (which is hard); the kernel should do better at preventing overloading from leading to unexpected aliasing (which they did). The MIT-SHM aspect just makes the exploit comprehensible.
I don't doubt that a sufficiently clever request could get the server to overflow the stack into the area where the response to the request will be written and write a chosen response into a spot that aliases a return address on the stack, causing the server to return to effectively calling system() on a chunk of an image provided by the client.
Xorg flaw Posted Aug 19, 2010 14:33 UTC (Thu) by NAR (subscriber, #1313) [Link] Looks like any X client can crash the server, with or without a patched kernel.If I understood correctly the problem (which is far from certain) the client can ask the server to allocate memory in the server's address space. Consequently the X server can run out of memory and the OOM killer can kill it. This seems to a be a feature, not a bug (i.e. the whole X server was designed this way). By the way, the X server uses the most memory on my system currently (according to top) and as far as I know, most of the memory is allocated on behalf of clients. Anyway, nowadays most X clients run locally and if a malicious attacker already controls a client locally, even if it doesn't find any local root holes (which I'm sure there are plenty of), he can delete all of the user's files, send e-mails in the user's name, etc.
Xorg flaw Posted Aug 21, 2010 9:12 UTC (Sat) by niner (subscriber, #26151) [Link]
"send e-mails in the user's name, etc."
Just because this is one of my favourite misconceptions floating around: nothing at all prevents anyone from sending e-mails in any user's name. Same as you can write any name as sender on an envelope of bad old snail mail. The only thing proving the identity of the sender is in both cases a signature. The electronic version even more so than your easy to fake hand writing. And of course, such a signature should not lie around on your computer unprotected...
Xorg flaw Posted Aug 23, 2010 23:42 UTC (Mon) by mgedmin (subscriber, #34497) [Link]
The bad thing that malicious programs can do is send emails using the user's bandwidth (and their IP, to avoid spam blacklists).
Xorg flaw Posted Aug 19, 2010 15:28 UTC (Thu) by HelloWorld (guest, #56129) [Link]
If it can't be done without crippling performance, they'll have to cripple it. Reliability is just more important.
|
|||||||||||||