3 ms·

Or it has to run on a memory safe architecture. http://phrack.org/issues/64/6.html http://phrack.org/issues/64/6.html "- separated kernel and process address

Or it has to run on a memory safe architecture. http://phrack.org/issues/64/6.html http://phrack.org/issues/64/6.html "- separated kernel and process address space (both can use the whole address space). Such an implementation, to be efficient, requires a dedicated support from the underlaining architecture. It is the case of the primary and secondary context register used in conjunction with the ASI identifiers on the UltraSPARC (sun4u/sun4v) architecture. The only limitation to kernel (and processes) virtual space on systems implementing an userland/kerneland separated address space is given by the architecture (UltraSPARC I and II can reference only 44bit of the whole 64bit addressable space. This VA-hole is placed among 0x0000080000000000 and 0xFFFFF7FFFFFFFFFF). This memory model makes explotation indeed harder, because we can't directly dereference the userspace. The previously cited NULL pointer dereferences are pretty much un-exploitable. Moreover, we can't rely on "valid" userland addresses as a place to store our shellcode (or any other kernel emulation data), neither we can "return to userspace"."

lunixbochs 9y ago
> separated kernel and process address space This already exists on x86_64 Linux in the form of SMEP and SMAP. > With SMEP enabled, it’s no longer possible to map exploit payloads in userland, as the CPU will trigger a fault if it attempts to execute those user pages in kernel mode http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/ http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-h... > SMEP can be used to prevent supervisor-mode code from unintentionally executing user-space code. SMAP extends this protection to reads and writes https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevent... These mitigations aren't overly novel at this point and don't prevent exploits (just complicates them). Here's a recent CVE PoC containing an SMEP and KASLR bypass: https://github.com/xairy/kernel-exploits/blob/master/CVE-2017-1000112/poc.c https://github.com/xairy/kernel-exploits/blob/master/CVE-201... Full memory safety takes this much further, and should be far harder to bypass.
- StreamBright 9y ago
  Good to know. I think there is no silver bullet in security so anything making exploitation harder is good.

lunixbochs 9y ago

> separated kernel and process address space This already exists on x86_64 Linux in the form of SMEP and SMAP. > With SMEP enabled, it’s no longer possible to map exploit payloads in userland, as the CPU will trigger a fault if it attempts to execute those user pages in kernel mode http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/ http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-h... > SMEP can be used to prevent supervisor-mode code from unintentionally executing user-space code. SMAP extends this protection to reads and writes https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevent... These mitigations aren't overly novel at this point and don't prevent exploits (just complicates them). Here's a recent CVE PoC containing an SMEP and KASLR bypass: https://github.com/xairy/kernel-exploits/blob/master/CVE-2017-1000112/poc.c https://github.com/xairy/kernel-exploits/blob/master/CVE-201... Full memory safety takes this much further, and should be far harder to bypass.

StreamBright 9y ago
Good to know. I think there is no silver bullet in security so anything making exploitation harder is good.