| |||||||||||||
The story restarts again and againThe story restarts again and againPosted Nov 5, 2009 0:58 UTC (Thu) by haypo (guest, #42675)Parent article: Another null pointer exploit
All exploits for the last famous local kernel vulnerabilities (vmsplice(),
tun_chr_pool(), perf_counter) use NULL pointer dereference. vmsplice() bug was found in february 2008. And the story restarts again and again. Why not setting /proc/sys/vm/mmap_min_addr *default value* to non zero value in Debian Stable or RedHat? Ubuntu, Debian Sid and Fedora all use non zero value. I read that mmap_min_addr causes issue with Qemu, dosemu and WINE (only old versions of Qemu and dosemu, and it was still possible to use them as root). But I think that most people prefer to be protected against root exploits than being able to use Qemu, dosemu, ... without any manual configuration.
About the new pipe bug/vulnerability, the funniest is that Brad Spengler
(Log in to post comments)
The story restarts again and again Posted Nov 5, 2009 2:59 UTC (Thu) by spender (subscriber, #23067) [Link]
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
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.
The story restarts again and again Posted Nov 5, 2009 13:42 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
There's a conflict between stability and security here. Debian stable probably will be updated to raise the default mmap_min_addr, but we need to clearly announce the change so that users that need DOS/Win16 compatibility know that they need to override it.
The story restarts again and again Posted Nov 5, 2009 13:58 UTC (Thu) by paravoid (subscriber, #32869) [Link]
This has already happened. Have a look at DSA 1915-1, dated 23/10/2009.
|
|||||||||||||
