Kernel security, year to date [LWN.net]

Kernel security, year to date

Posted Sep 10, 2008 15:22 UTC (Wed) by spender (subscriber, #23067)
In reply to: Kernel security, year to date by paulj
Parent article: Kernel security, year to date

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

(Log in to post comments)

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..