http://www.invisiblethingslab.com/re...ry-attacks.pdf
Both the local and the remote attacker must be authenticated users. That is, they must be logged into the system "Remote" users are those, for example, that have ssh accounts. Hackers trying to break into ports are not "remote" users. And, x86_64 systems are less vulnerable.
Basically, it a matter of trust. If you can't trust your users you have other problems. This is probably why, even after five years, an exploit for this has not been seen in the wild.
I don't know how long it will take the new kernels to filter through the system and reach our boxes, but it wouldn't surprise me to see a 34.4 or 35.2 kernel in the repository within a week. Systems with single users have nothing to worry about. For the rest, don't let your precocious kids log into their accounts.
Note that depending on the system configuration, by default local unprivileged users may be able to start an instance of Xorg server that requires no authentication and exploit it. Also if a remote attacker exploits a (unrelated) vulnerability in a GUI application (e.g. web browser), he will have ability to attack X server.
In case of a local attacker that can use MIT-SHM extension (which is the most likely scenario), the exploit is very reliable.
Identifier CVE-2010-2240 has been reserved for the underlying issue (Linux kernel not providing stack and heap separation). This issue has been known for at least five years.
...
The Linux kernel versions that include the commit from Linus tree are fixed. Particularly, 2.6.35.2 and 2.6.34.4 are fixed.
...
In response to prevent the described attack (and similar ones), the generic solution implemented in recent Linux kernels is to keep the top page of stack VMA unmapped; in other words, maintain a one-page gap between the stack and the rest of the areas.
Timeline
• 17 June 2010 - ITL notifies X.org security team about the vulnerability
• 20 June 2010 - X.org security team suggests to discuss the issue with Linux kernel developers, as the proper solution should be implemented in the kernel
• 13 Aug 2010 - the fix is committed to Linus tree [4]
• 17 Aug 2010 - the paper is published
In case of a local attacker that can use MIT-SHM extension (which is the most likely scenario), the exploit is very reliable.
Identifier CVE-2010-2240 has been reserved for the underlying issue (Linux kernel not providing stack and heap separation). This issue has been known for at least five years.
...
The Linux kernel versions that include the commit from Linus tree are fixed. Particularly, 2.6.35.2 and 2.6.34.4 are fixed.
...
In response to prevent the described attack (and similar ones), the generic solution implemented in recent Linux kernels is to keep the top page of stack VMA unmapped; in other words, maintain a one-page gap between the stack and the rest of the areas.
Timeline
• 17 June 2010 - ITL notifies X.org security team about the vulnerability
• 20 June 2010 - X.org security team suggests to discuss the issue with Linux kernel developers, as the proper solution should be implemented in the kernel
• 13 Aug 2010 - the fix is committed to Linus tree [4]
• 17 Aug 2010 - the paper is published
Both the local and the remote attacker must be authenticated users. That is, they must be logged into the system "Remote" users are those, for example, that have ssh accounts. Hackers trying to break into ports are not "remote" users. And, x86_64 systems are less vulnerable.
Basically, it a matter of trust. If you can't trust your users you have other problems. This is probably why, even after five years, an exploit for this has not been seen in the wild.
I don't know how long it will take the new kernels to filter through the system and reach our boxes, but it wouldn't surprise me to see a 34.4 or 35.2 kernel in the repository within a week. Systems with single users have nothing to worry about. For the rest, don't let your precocious kids log into their accounts.
I just mentioned it that way around as a tease because from the reports it looks like everybody forgot that it works both ways. The digital world is distinctly different from physical reality in that way. You could fall into a hole in the road even if you didn't know it was there, but you couldn't execute a vulnerability without knowing it's existence. A vulnerability doesn't actually exist until someone knows about it. If it was 20 years it would be even better, except of course that it might be harder to fix then. 
Comment