|
|
XNU kernel heap overflow due to bad bounds checking in MPTCP |
||
Issue description
mptcp_usr_connectx is the handler for the connectx syscall for the AP_MULTIPATH socket family.
The logic of this function fails to correctly handle source and destination sockaddrs which aren't
AF_INET or AF_INET6:
// verify sa_len for AF_INET:
if (dst->sa_family == AF_INET &&
dst->sa_len != sizeof(mpte->__mpte_dst_v4)) {
mptcplog((LOG_ERR, "%s IPv4 dst len %u\n", __func__,
dst->sa_len),
MPTCP_SOCKET_DBG, MPTCP_LOGLVL_ERR);
error = EINVAL;
goto out;
}
// verify sa_len for AF_INET6:
if (dst->sa_family == AF_INET6 &&
dst->sa_len != sizeof(mpte->__mpte_dst_v6)) {
mptcplog((LOG_ERR, "%s IPv6 dst len %u\n", __func__,
dst->sa_len),
MPTCP_SOCKET_DBG, MPTCP_LOGLVL_ERR);
error = EINVAL;
goto out;
}
// code doesn't bail if sa_family was neither AF_INET nor AF_INET6
if (!(mpte->mpte_flags & MPTE_SVCTYPE_CHECKED)) {
if (mptcp_entitlement_check(mp_so) < 0) {
error = EPERM;
goto out;
}
mpte->mpte_flags |= MPTE_SVCTYPE_CHECKED;
}
// memcpy with sa_len up to 255:
if ((mp_so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) == 0) {
memcpy(&mpte->mpte_dst, dst, dst->sa_len);
}
This PoC triggers the issue to overwrite the mpte_itfinfo field leading to a controlled pointer
being passed to kfree when the socket is closed.
Please note that these lengths seem to be trusted in multiple places - I would strongly suggest auditing
this code quite thoroughly, especially as mptcp can be reached from more places as of iOS 11.
Note that the MPTCP code does seem to be quite buggy; trying to get a nice PoC working for this buffer overflow
bug I accidentally triggered the following error path:
error = socreate_internal(dom, so, SOCK_STREAM, IPPROTO_TCP, p,
SOCF_ASYNC, PROC_NULL);
mpte_lock(mpte);
if (error) {
mptcplog((LOG_ERR, "%s: subflow socreate mp_so 0x%llx unable to create subflow socket error %d\n",
(u_int64_t)VM_KERNEL_ADDRPERM(mp_so), error),
MPTCP_SOCKET_DBG, MPTCP_LOGLVL_ERR);
proc_rele(p);
mptcp_subflow_free(mpts);
return (error);
}
note that first argument to mptcplog has one too few arguments. It's probably not so interesting from a security
POV but is indicative of untested code (this error path has clearly never run as it will always kernel panic.)
This PoC is for MacOS but note that this code is reachable on iOS 11 from inside the app sandbox if you give yourself
the multipath entitlement (which app store apps can now use.)
Just run this PoC as root on MacOS for easy repro.
,
Jun 5
Fixed in MacOS 10.13.5: https://support.apple.com/en-us/HT208849 Fixed in iOS 11.4: https://support.apple.com/en-us/HT208848
,
Jun 5
Exploit for iOS 11.0 - 11.3.1 attached.
,
Jun 5
,
Jun 5
Interesting find, the Jailbreak community will be all over this (they already are though)
,
Jun 6
amazing find. the exploit looks very clean and can be triggered at multiple places. I hope Apple mistakingly won't fix all of the places where this issue is occurring; getting a jailbreak for 11.4, and/or 12 would be great haha.
,
Jun 6
I get a constant, reproducible kernel panic on the iPad 6,11 (J71tAP) when attempting to run this exploit. The panic occurs when the kernel attempts to read from an invalid address 0x4242424242424252. Here's the panic string: panic(cpu 1 caller 0xfffffff00b3af5a0): Kernel data abort. (saved state: 0xffffffe02787b4f0) x0: 0xffffffe00bffa6f8 x1: 0x0000000000000000 x2: 0x0000000000000003 x3: 0x0000000000000000 x4: 0x00000000ffffffff x5: 0x0000000000000001 x6: 0xffffffe002366d90 x7: 0x0000000000000000 x8: 0x0000000000000001 x9: 0x0000000000000000 x10: 0x0000000000000000 x11: 0x0000000000000028 x12: 0xffffffe02787b7d8 x13: 0x00000000b3890b1d x14: 0x0000000000000bff x15: 0x0000000000000000 x16: 0xfffffff00a6669e0 x17: 0x0000000000000000 x18: 0xfffffff00b29d000 x19: 0xffffffe00c000000 x20: 0xffffffe00bffa6f8 x21: 0x4242424242424242 x22: 0x4242424242424242 x23: 0xffffffe00bffa6f8 x24: 0x0000000000000000 x25: 0xffffffe0036c5040 x26: 0x0000000000000000 x27: 0xffffffe00280e540 x28: 0x0000000000000000 fp: 0xffffffe02787b880 lr: 0xfffffff00b2b6c4c sp: 0xffffffe02787b840 pc: 0xfffffff00b2af3f0 cpsr: 0x00000204 esr: 0x96000004 far: 0x4242424242424252 The faulting instruction is "LDR X8, [X21,#0x10]" and corresponds to the function ipc_kmsg_rmqueue. I've also narrowed down the crash to the following code: // write the empty prealloc message back over the pipe: write(replacer_pipe+1, msg_contents, PIPE_SIZE); I'm unsure if this is the exact function causing the crash as sometimes execution continues for ~1 second before panicking. I'd be glad if anyone here can help me fix this crash. Also, thanks for all the work.
,
Jun 6
You have to Disable Siri for this to work , for me it was kernel panics too till i disabled siri |
|||
►
Sign in to add a comment |
|||
Comment 1 by ianbeer@google.com
, Apr 9