Exploit-DB #46297
Description: macOS < 10.14.3 / iOS < 12.1.3 - Arbitrary mach Port Name Deallocation in XPC Services due to Invalid mach Message Parsing in _xpc_serializer_unpack
Type: dos
Platform: multiple
Date: 2019-01-31
Author: Google Security Research

Exploit:
/*
_xpc_serializer_unpack in libxpc parses mach messages which contain xpc messages.

There are two reasons for an xpc mach message to contain descriptors: if the message body is large, then it's sent as
a MACH_MSG_OOL_DESCRIPTOR. Also if the message contains other port resources (eg memory entry ports) then
they're also transfered as MACH_PORT_OOL_PORT descriptors.

Whilst looking through a dump of system mach message traffic gathered via a dtrace script I noticed something odd:
It's possible for a message to have the MACH_MSGH_BITS_COMPLEX bit set and also have a msgh_descriptor_count of 0.

Looking at ipc_kmsg_copyin_body you can see that this is in fact the case.

This is a kinda surprising fact, and I think there are likely to be multiple places where developers are going to
have assumed that there must be at least one descriptor if MACH_MSGH_BITS_COMPLEX is set.

It turns out that libxpc does exactly that in _xpc_serializer_unpack:

__text:[PII_REDACTED]                 cmp     dword ptr [rbx], 0        ; rbx points to the start of the mach message
__text:[PII_REDACTED]                 js      short loc_703F            ; branch if the COMPLEX bit is set
...
__text:[PII_REDACTED]00703F loc_703F:                               ; CODE XREF: __xpc_serializer_unpack+67↑j
__text:[PII_REDACTED]00703F                 mov     rax, rbx
__text:[PII_REDACTED]                 mov     edx, [rax+18h]            ; read msgh_descriptor_count, which could be 0
__text:[PII_REDACTED]                 add     rbx, 1Ch                  ; point rbx to the first descriptor
__text:[PII_REDACTED]                 mov     ecx, 0FF000000h
__text:[PII_REDACTED]00704E                 and     ecx, [rax+24h]
__text:[PII_REDACTED]                 cmp     ecx, 1000000h             ; is the type OOL_DESC?
__text:[PII_REDACTED]                 jnz     short loc_7089
__text:[PII_REDACTED]                 or      byte ptr [r12+0ACh], 4    ; yes, then set this bit
__text:[PII_REDACTED]                 mov     r9, [rbx]                 ; save the address field
__text:[PII_REDACTED]                 mov     r15d, [rbx+0Ch]           ; and size field for later
__text:[PII_REDACTED]                 lea     rax, __xpc_serializer_munmap
__text:[PII_REDACTED]                 mov     [r12+48h], rax
__text:[PII_REDACTED]                 dec     edx                       ; decrement msgh_descriptor_count, so could now be 0xffffffff
__text:[PII_REDACTED]                 mov     dword ptr [rbx+0Ch], 0    ; clear the size in the message
__text:[PII_REDACTED]00707E                 lea     rbx, [rbx+10h]            ; skip over this desc
__text:[PII_REDACTED]                 mov     eax, 2Ch ; ','
__text:[PII_REDACTED]                 jmp     short loc_7094
__text:[PII_REDACTED]                 test    edx, edx                  ; test whether msgh_descriptor_count is now 0
__text:[PII_REDACTED]                 jz      loc_713E                  ; but we've decremented it to 0xffffffff :)

The code the goes on to read up to 0xffffffff port descriptors, storing the names and dispositions in two arrays.

By specifying an invalid disposition we can stop the loop, the serializer will then return an error and be destructed
which will cause names read from our fake descriptors to be passed to mach_port_deallocate().

You can test this PoC by attached lldb to the chosen target, setting a breakpoint on mach_port_deallocate and waiting
for the port name 0x414141 to be passed in rsi.

There is one mitigating factor which might prevent this from being exploitable on iOS: the underflowed value is used for two memory allocations
so you need to be able to reserve around 32G of RAM, on MacOS this is no problem but doesn't seem to be so easy on my XS.

Still, it would be a nice sandbox escape on MacOS.

Tested on MacOS 10.14.1 (18B75)
*/

// ianbeer
#if 0
Arbitrary mach port name deallocation in XPC services due to invalid mach message parsing in _xpc_serializer_unpack

_xpc_serializer_unpack in libxpc parses mach messages which contain xpc messages.

There are two reasons for an xpc mach message to contain descriptors: if the message body is large, then it's sent as
a MACH_MSG_OOL_DESCRIPTOR. Also if the message contains other port resources (eg memory entry ports) then
they're also transfered as MACH_PORT_OOL_PORT descriptors.

Whilst looking through a dump of system mach message traffic gathered via a dtrace script I noticed something odd:
It's possible for a message to have the MACH_MSGH_BITS_COMPLEX bit set and also have a msgh_descriptor_count of 0.

Looking at ipc_kmsg_copyin_body you can see that this is in fact the case.

This is a kinda surprising fact, and I think there are likely to be multiple places where developers are going to
have assumed that there must be at least one descriptor if MACH_MSGH_BITS_COMPLEX is set.

It turns out that libxpc does exactly that in _xpc_serializer_unpack:

__text:[PII_REDACTED]                 cmp     dword ptr [rbx], 0        ; rbx points to the start of the mach message
__text:[PII_REDACTED]                 js      short loc_703F            ; branch if the COMPLEX bit is set
...
__text:[PII_REDACTED]00703F loc_703F:                               ; CODE XREF: __xpc_serializer_unpack+67↑j
__text:[PII_REDACTED]00703F                 mov     rax, rbx
__text:[PII_REDACTED]                 mov     edx, [rax+18h]            ; read msgh_descriptor_count, which could be 0
__text:[PII_REDACTED]                 add     rbx, 1Ch                  ; point rbx to the first descriptor
__text:[PII_REDACTED]                 mov     ecx, 0FF000000h
__text:[PII_REDACTED]00704E                 and     ecx, [rax+24h]
__text:[PII_REDACTED]                 cmp     ecx, 1000000h             ; is the type OOL_DESC?
__text:[PII_REDACTED]                 jnz     short loc_7089
__text:[PII_REDACTED]                 or      byte