| |||||||||||||
Kernel security, year to dateKernel security, year to datePosted Sep 9, 2008 22:17 UTC (Tue) by bfields (subscriber, #19510)In reply to: Kernel security, year to date by spender Parent article: Kernel security, year to date
Read: http://seclists.org/dailydave/2007/q1/0224.html Following that to the tarball, to the included README.... So the answer is just "mmap buffer at address 0", then trigger the bug that results in calling a function at 0 (or some small offset from that). OK. (Stupid question: are those low addresses always available? I would've thought you'd want to treat the first and last page of the address space specially, exactly to increase the chances of catching such a typical mistake.)
(Log in to post comments)
Kernel security, year to date Posted Sep 9, 2008 22:23 UTC (Tue) by paulj (subscriber, #341) [Link] Nah, RIP==0 implies the IP got corrupted (e.g. through stack overflow), which almost certainly means it can be manipulated..
Kernel security, year to date Posted Sep 9, 2008 22:45 UTC (Tue) by spender (subscriber, #23067) [Link]
Not necessarily: all the world isn't a stack overflow (they're actually
quite rare in the kernel). In this case it's much more likely that it was just jumping/calling through a null function pointer -- no tricks needed, just straightforward arbitrary code execution.
-Brad
Kernel security, year to date Posted Sep 9, 2008 23:02 UTC (Tue) by nix (subscriber, #2304) [Link]
Jumping through a null fp could have been a simple bug. There's no
requirement for the content of the pointer to be manipulable by external sources. (Of course it's quite possible, and even the nice case would still make it a DoS attack, and speaks of a missed case in testing, at least: but the kernel has so many configuration options, runs on such a variety of hardware, and makes such heavy use of function pointers that complete coverage of these situations is never going to happen. Alas.
It *is* interesting that most of the holes aren't in old crufty driver
Kernel security, year to date Posted Sep 9, 2008 23:21 UTC (Tue) by jreiser (subscriber, #11027) [Link] the kernel ... makes such heavy use of function pointers that complete coverage of these situations is never going to happen. Why not? Build an option to gcc that tests for zero at every invocation of a non-lexical function, then make that option the default when compiling for Linux kernel. Or, have every interrupt and syscall map a replacement if page 0 already has a user-level mapping.
Kernel security, year to date Posted Sep 10, 2008 8:57 UTC (Wed) by nix (subscriber, #2304) [Link]
Both of these options would be really really -really- expensive (especially the latter: page table manipulation is expensive). The first one has more promise: GCC already has *some* code to insert automatic tests against NULL, it just isn't hooked up in the right places
Kernel security, year to date Posted Sep 10, 2008 4:46 UTC (Wed) by paulj (subscriber, #341) [Link] I very deliberately used "e.g." rather than "i.e." wrt "stack overflow" (I've little idea about how exploits usually work). ;) How does this null function pointer attack work?
Kernel security, year to date Posted Sep 10, 2008 15:22 UTC (Wed) by spender (subscriber, #23067) [Link]
Though I specifically noted the stack overflow case, I was rejecting the general notion that the null ptr dereference was due to some attacker-influenced manipulation or control of kernel data.
These bugs generally crop up from having incomplete handling of all possible cases of working with a pointer. The most fruitful ones are the bugs where it involves using a null pointer to a structure containing a function pointer, or simply a null function pointer itself. The kernel has a ton of the first case: it's the way in which abstractions are made. These grant trivial arbitrary code execution on x86 (just map your code at address 0 and it gets executed in kernel context), whereas in other cases these bugs can be used to provide the kernel with trojaned data -- though the usefulness of this for DoS or privilege elevation has to be determined on a case-by-case basis.
-Brad
Kernel security, year to date Posted Sep 11, 2008 10:01 UTC (Thu) by nix (subscriber, #2304) [Link]
It seems like we should add CAP_LOW_MAP_FIXED to me, set off for virtually everything other than Wine (and the X server, and perhaps a few Lisp interpreters?), and deny MAP_FIXED mmap()s in the low megabyte or so of the address space to processes without that capability. It's not as though most programs would *want* to torpedo their own ability to segfault on null pointer dereferences!
Kernel security, year to date Posted Sep 11, 2008 14:14 UTC (Thu) by paulj (subscriber, #341) [Link]
Huh.. wow. I thought the kernel took care of setting RO mappings for page 0 (and more - the low "ASCII range" of addresses?) to ensure faults, as a security measure (for userspace primarily).
If not, wow. Bring back the seperate user/kernel address space..
Kernel security, year to date Posted Sep 9, 2008 22:31 UTC (Tue) by spender (subscriber, #23067) [Link]
The bugclass is larger than just allocating at 0, it involves all invalid
userland dereferences. So for example, there have been bugs where a pointer was used which had a magic poison value in it, and this poison value resulted in an address which was located somewhere in the middle of the userland address space.
Openwall implemented HARDENED_PAGE0, and a derivative of it has been
-Brad
|
|||||||||||||