Ian Beer of Google's Project Zero has followed up on a “coming soon” Twitter teaser with a jailbreakable iOS and Mac OS vulnerability.

Beer went public after Apple worked out a fix for the kernel memory corruption bug.

He even launched a Twitter account for the occasion:

If you're interested in bootstrapping iOS 11 kernel security research keep a research-only device on iOS 11.1.2 or below. Part I (tfp0) release soon. — Ian Beer (@i41nbeer) December 5, 2017

(For non-programmers: tfp0 stands for “task for pid 0” – the kernel task port, and therefore the vector for pwnage.)

iOS 11.1.2, now with more kernel debugging: https://t.co/PIKbD3Gwx9 — Ian Beer (@i41nbeer) December 11, 2017

tfp0 should work for all devices, the PoC local kernel debugger only for those I have to test on (iPhone 7, 6s and iPod Touch 6G) but adding more support should be easy — Ian Beer (@i41nbeer) December 11, 2017

The release is designed to let others take their own toolkits to Apple devices, ultimately to improve their security: if you don't need to jailbreak a device, Apple had already patched the bugs last week.

The issue Beer found starts with Apple's Mach kernel implementation, and the Mach interface generator (MIG). Beer was already familiar with MIG's behaviour, having turned up CVE-2016-7612 and CVE-2016-7633 last year, and in September 2016 wrote: “Exploitability hinges on being able to get the memory reallocated in between the two vm_deallocate calls, probably in another thread.”

A second bug detailed in Beer's proof-of-concept provided the vector to attack MIG. He writes that he took advantage of “a recent addition to the kernel, presumably as a debugging tool to help enumerate places where the kernel is accidentally disclosing pointers to userspace. The implementation currently enumerates kqueues and dumps a bunch of values from them.”

Beer's step-by-step explanation is in the readme file of his PoC (linked in the Project Zero post):

First, he used a proc_pidlistuptrs bug to disclose the address of arbitrary ipc_ports ;

bug to disclose the address of arbitrary ; Second, he triggered an out-of-bounds read for “various kalloc sizes” to identify “the most commonly-leaked kernel pointer”;

sizes” to identify “the most commonly-leaked kernel pointer”; Next, he sent Mach messages to gather “a pretty large number of kalloc allocations;

allocations; With enough Mach port allocations, Beer gathered a page “containing only my ports”. The port address disclosure provided “a port which fits within particular bounds on a page. Once I've found it, I use the IOSurface bug to give myself a dangling pointer to that port”;

”I free the kalloc allocations made earlier and all the other ports then start making kalloc.4096 allocations (again via crafted mach messages);”

allocations made earlier and all the other ports then start making allocations (again via crafted mach messages);” Careful reallocation (1 MB at a time) made garbage collection trigger and “collect the page that the dangling pointer points to”.

Beer continued that “the bsdinfo->pid trick” let him build an arbitary read to find the kernel task's vm_map and the kernel's ipc_space , allowing him to reallocate the kalloc.4096 buffer with a fake kernel task port.

Beer said he had tested the exploit on iPhone 6s, iPhone 7, iPod Touch 6G, and Mac OS 10.13 on a MacBook Air 5.2 ®