| |||||||||||||
The rest of the vmsplice() exploit storyThe rest of the vmsplice() exploit storyPosted Mar 6, 2008 14:29 UTC (Thu) by fuhchee (subscriber, #40059)Parent article: The rest of the vmsplice() exploit story
> Also worth noting is the fact that ordinary buffer overflow protection may > well have not been effective against this vulnerability. The return address > on the stack was not overwritten, and no exploit code was put in data > areas. Has there been any talk about extending NX (no-execute) style page protection to within kernel space itself, to prevent it from executing code residing in user-space pages?
(Log in to post comments)
The rest of the vmsplice() exploit story Posted Mar 6, 2008 20:05 UTC (Thu) by spender (subscriber, #23067) [Link] The UDEREF feature of PaX prevents the kernel from accessing userland memory directly and has been doing so for 2 years now, close to a year before the vulnerability class ever became public. It makes use of segmentation on x86 to accomplish this, so due to Linus' rules it will never be accepted into the mainline kernel. -Brad
The rest of the vmsplice() exploit story Posted Mar 6, 2008 20:11 UTC (Thu) by spender (subscriber, #23067) [Link] If you're interested, I had posted this information earlier regarding UDEREF to some mailing lists, courtesy of the PaX Team: http://grsecurity.net/~spender/uderef.txt -Brad
|
|||||||||||||