New issue
Advanced search Search tips
Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 5
Cc:


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

XNU kernel heap overflow due to bad bounds checking in MPTCP

Project Member Reported by ianbeer@google.com, Apr 9

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.
 
mptcp.c
3.6 KB View Download
Project Member

Comment 1 by ianbeer@google.com, Apr 9

Labels: Reported-2018-Apr-09 Id-688883229
Project Member

Comment 2 by ianbeer@google.com, Jun 5

Labels: Fixed-2018-May-29 CVE-2018-4241
Status: Fixed (was: New)
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
Project Member

Comment 3 by ianbeer@google.com, Jun 5

Exploit for iOS 11.0 - 11.3.1 attached.
multi_path.zip
52.8 KB Download
Project Member

Comment 4 by ianbeer@google.com, Jun 5

Labels: -Restrict-View-Commit

Comment 5 Deleted

Interesting find, the Jailbreak community will be all over this (they already are though)
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.
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.
You have to Disable Siri for this to work , for me it was kernel panics too till i disabled siri

Comment 10 Deleted

Comment 11 Deleted

Sign in to add a comment