IOKit is the main interface to write drivers in Mac OSX. it’s unlike most other driver interfaces for other operating systems. the data parsing code where the trust boundary is passed is not a simple ioctl() call away, and it’s not written in c (they’re written in c++). A complex system that goes through mach messages and uses rpc is used to communicate with drivers, oh, and it’s virtually undocumented (and the documentation that is there is poorly written at best).

This talk will describe what I’ve found out in my journey as I try to figure out how the IOKit works, and what exactly an attacker has control over (e.g. what pointers are userland pointers, whats the length limitation placed on them, is the buffer already captured by the time it reaches input handling code, …). The IOKit also has several entrypoints, 2 different ways of using 1 entrypoints and offers the possibility to expose 1 system call specifically for your driver.

Once the basics are covered this lecture will go into possible security issuess that come with the IOKit, e.g. which mechanism have a lot of potential for abuse, what types of bugs are possible, and show some real bugs as evidence thereof, both in drivers and in the inner workings of the IOKit itself.

Lastly this talk will discuss fuzzing the IOKit, what approches might be best, what to avoid, what to fuzz, etc… An IOKit fuzzer will also be released.

About Ilja