CVE-2017-2370 Compatibility and Offsets

[OothecaPickle]

This may seem like a really dumb question, but is CVE-2017-2370 compatible with 32-bit devices, specifically the iPhone5,2? If so, what is the off0 variable in extra_recipe and how can I find it using my disassembler? I've already found the other offsets and added them to my fork (https://github.com/OothecaPickleGNUrmsT ... e-iOS-10.2). P.S. I've already decrypted and disassembled an iPhone5,2 iOS 10.2 kernelcache and I'm using Hopper to disassemble. Any help would be greatly appreciated.

[morpheus]

Hardly a dumb question at all - CVE-2017-2370 is indeed "compatible", as bugs go. The bug is very well present, BUT it's not just a matter of offsets -
In 32-bits the structure sizes are different (owing to sizeof(void *)), so you need to not only get the offsets right, but also the hard coded values for the port object (0xa8) and kdata (0x68).

[OothecaPickle]

Thanks for the reply! I'm not exactly sure what that means (although I will do my best to find out) as I'm only in middle school and am still a beginner at all of this, but I'm still not quite sure what the off0 variable is in extra_recipe. Thanks again, Zach.

[morpheus]

Then let me explain further:

The exploit relies on overwriting kernel objects, and creating a fake kernel object that is "as-if" a Mach port. Those are defined in osfmk/ipc/ipc_port.h like so:

struct ipc_port {

/*
* Initial sub-structure in common with ipc_pset
* First element is an ipc_object second is a
* message queue
*/
struct ipc_object ip_object;
struct ipc_mqueue ip_messages;

union {
struct ipc_space *receiver;
struct ipc_port *destination;
ipc_port_timestamp_t timestamp;
} data;

union {
ipc_kobject_t kobject;
ipc_importance_task_t imp_task;
uintptr_t alias;
} kdata;

struct ipc_port *ip_nsrequest;
....

Each of the "*" you see there is a pointer. The size of a pointer is 4 bytes in 32-bit archs and 8 bytes in 64-bit. This means that "kdata.kobject" - which is at offset 0x68 (104) in 64-bits will be elsewhere in 32-bit. So you'd have to adjust when you look at Luca's code. ok?

[OothecaPickle]

Yes, thanks again!

[OothecaPickle]

In all honesty, I still have no clue what any of that means. If you could just point me to the specific sections of code that need to be changed in Ian's extra_recipe, explain to me what to look for when disassembling a kernelcache (if applicable), tell me what to look for in the XNU source (if applicable), and explain how to find the correct offsets in the most dumbed-down, simple way possible, that would be great. Sorry if I'm asking these questions in the wrong place; I'm a complete beginner and have no idea what I'm doing. I also don't mean to be demanding or annoying or anything, and if you don't have the time to explain to me what any of this means, that's perfectly fine and I'm sorry for wasting your time. By the way, I've already downloaded the source code for XNU 3789.31.2, decompressed an iPhone5,2 iOS 10.2 kernelcache, and I have read the README in the extra_recipe Xcode project, as well as the explanations found here: https://bugs.chromium.org/p/project-zer ... il?id=1004 Thanks again, Zach.

[nottab0t]

Hey Pickle,

I don't think J will be able to pull off all those things you're asking for. That's basically solving the problem! Which would be taking away all your fun. It's pretty cool that you're interested in learning some lower-level programming, even if it's just in pursuit of the fact that you're stuck with a 32-bit phone and willing to chase answers to get your own "jailbrek!"

If you see how much work Jonathan goes through to protect his works from piracy, I'm not about to link a PDF of this book. Rest assured, it's out there if you look, and I think it could help. I bet things would be a lot clearer after just the first two chapters.

http://www.apress.com/us/book/9781430235361

[OothecaPickle]

Thanks, nottab0t.

[bob969]

I tried to port mach_portal to a 32 bit device and haven't been able to get it to work. I went through and found all of the required structure offsets in offsets.c and defined them as a new platform. However, the kernel exploit fails every time. I get past the races and win them according to the debug output, but the leaked pointer in the ipc_port->context field is always 0. This is obviously wrong and continuing past that point causes a reboot.

In the send_ool_ports() function I found the context offset (0x90) hardcoded so i updated it to the 32-bit offset and also changed the size of the ipc_port structure from 0xa8 throughout the kernel_sploit.c file. In this same function he iterates through the ports setting index = (obj_offset & 0xfff) / 8. What exactly is he trying to do here? Is there a reason for going through the ports in this order? I tried changing the 8 to a 4 in case it was pointer size but it didn't help any.

Are the kernel zones set up the same 32 and 64 bit builds or will I also need to adjust the zone Feng Shui to get a working 32 bit port?