Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
"3. Allocate windows arranged so that when X processes them, some function
F is called recursively. Trigger F recursion."
Looks like any X client can crash the server, with or without a patched kernel.
Posted Aug 19, 2010 3:21 UTC (Thu) by xtifr (subscriber, #143)
In any case, runaway memory use already puts your processes in the whimsical hands of the OOM-killer.
Posted Aug 19, 2010 17:32 UTC (Thu) by iabervon (subscriber, #722)
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.
Posted Aug 19, 2010 14:33 UTC (Thu) by NAR (subscriber, #1313)
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.
Posted Aug 21, 2010 9:12 UTC (Sat) by niner (subscriber, #26151)
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...
Posted Aug 23, 2010 23:42 UTC (Mon) by mgedmin (subscriber, #34497)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds