| |||||||||||||
The story restarts again and againThe story restarts again and againPosted Nov 5, 2009 2:59 UTC (Thu) by spender (subscriber, #23067)In reply to: The story restarts again and again by haypo Parent article: Another null pointer exploit
vmsplice on 64bit kernels wasn't a NULL ptr deref (see http://lwn.net/Articles/271874/). perf_counter wasn't either (I released 2 versions of it -- one that used a NULL deref and one that didn't)
From reading slashdot comments I was surprised how many people were posted with mmap_min_addr set to 0, and seeming surprised or not understanding why it had been turned off. It was also worrisome to see people just check the value and determine that that meant they were protected -- which is not necessarily the case, particularly for RHEL. I don't know what kind of standards are in place for this, but it seems like a user-visible warning should be given (like the ones I see on Debian) if a user is installing something that will force mmap_min_addr off. Some people reported that it was turned off, but all their apps worked fine -- could the request to disable the feature be moved to the application for when it's actually used?
Anyway, I wouldn't try to over-analyze the threatscape of the kernel based purely on exploits I release publicly.
FYI, the exploit was released tonight with a video and an OpenBSD history lesson.
-Brad
(Log in to post comments)
The story restarts again and again Posted Nov 5, 2009 3:01 UTC (Thu) by spender (subscriber, #23067) [Link]
All their apps worked fine with it turned back on, I meant to say.
The story restarts again and again Posted Nov 5, 2009 19:20 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
All of this is just patching the symptoms. The kernel should be secure against NULL pointer exploits regardless of the value of mmap_min_addr.
This is a case of security being badly compromised for the sake of performance. If the hardware doesn't support limiting supervisor access to the NULL page while allowing user accesses, and the overhead of updating the page tables when moving between user and supervisor mode is too high, then the page(s) should be permanently unmapped with user-space accesses emulated in the page-fault handler. That would allow (much slower) access to these infrequently-used pages without kernel security compromises.
|
|||||||||||||