| |||||||||||||
Kernel security, year to dateKernel security, year to datePosted Sep 9, 2008 22:23 UTC (Tue) by paulj (subscriber, #341)In reply to: Kernel security, year to date by bfields Parent article: Kernel security, year to date Nah, RIP==0 implies the IP got corrupted (e.g. through stack overflow), which almost certainly means it can be manipulated..
(Log in to post comments)
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..
|
|||||||||||||