OS X IOKit Multiple exploitable kernel NULL dereferences (x4) about google-security-research HOT 11 CLOSED

(The minimum address field of the vm_map_t is min_offset, not min_addr - I 
corrected this before I sent the report to apple)

Apple replied on May 16th. The asked me to keep their reply confidential so 
I'll summarise:

 * They know that the NULL page is mappable, it may be fixed, who knows when.
 * They think there are mitigating circumstances for exploiting this.

I replied on May 22nd asking for further details of the mitigating 
circumstances, since I've verified that these bugs get you kernel RIP from 
inside the chrome sandbox. I offered to share an actual exploit with them 
rather than just a PoC which panics at a controlled address.

Apple sent me a draft of the advisory for these bugs. The advisory isn't clear 
on the exploitability of these bugs in 32-bit vs 64-bit processes (well, 
whether the mach-o which was loaded was 32-bit or 64-bit.)

The advisory claims that a "maliciously crafted 32-bit executable" is required 
- that isn't the case. The NULL page is *always* mappable for a sandboxed 
32-bit process, you don't need to craft the executable at all.

You do need to maliciously craft a 64-bit executable (pass a linker flag to 
remove the __PAGEZERO segment.)

I sent apple an example of how to exploit these bugs from a 64-bit process 
(attached) and explained in more detail that these bugs don't require any 
modifications of 32-bit executables to be exploited (and therefore are 
exploitable from, for example, the chrome GPU sandbox.)

Apple advisory: http://support.apple.com/kb/HT6296