-
Notifications
You must be signed in to change notification settings - Fork 1
IOKit
We store information regarding the IOKit framework and iOS drivers for the iOracle project.
- Slides from a presentation about exploiting IOKit to escape from a sandbox
- Video of presentation on IOKit fuzzing 2015
You should find the drivers in the kernel. I think that they are kernel extensions or something similar. Each driver will offer multiple iokit user clients. One of the first things we should build is a mapping of each iokit user client to the driver that offers it.
Content of an old email from Luke when he first started investigating IOKit user clients:
I mostly understand iokit user clients now. They are services provided by drivers in the kernel which cross the user space-kernel space boundary. This makes them extremely dangerous because they seem to be a good way for apps to interact with the kernel and introduce exploits. Cutting off iokit user clients with the sandbox should significantly reduce the attack surface for an app.
I can't figure out how to tell exactly which user client an app will use, but I think I can tell which drivers they will use. Each driver seems able to provide multiple user clients... In the dyld_shared_cache there is a function called IOServiceMatching. It is always called with a driver name specified in register 0 as a string. I should be able to make an IDA script that detects this function and the driver in the string before it. If the app can reach this section of code, it can use the driver specified in register 0.
By knowing which drivers an app will use, we can tighten the sandbox further by denying access to user clients of drivers the app should not need.
There seem to be 15 iokit user clients allowed by container, but my experiments suggests that only 1 of these is essential. The other 14 should only be allowed if the app uses the services provided.
Best, Luke