Exploit-DB #42056
Description: Apple macOS - Lack of Bounds Checking in HIServices Custom CFObject Serialization Local Privilege Escalation
Type: dos
Platform: macos
Date: 2017-05-23
Author: Google Security Research

Exploit:
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1219

HIServices.framework is used by a handful of deamons and implements its own CFObject serialization mechanism.

The entrypoint to the deserialization code is AXUnserializeCFType; it reads a type field and uses that
to index an array of function pointers for the support types:

__const:[PII_REDACTED]053ED0 _sUnserializeFunctions dq offset _cfStringUnserialize
__const:[PII_REDACTED]053ED0                                         ; DATA XREF: _AXUnserializeCFType+7Co
__const:[PII_REDACTED]053ED0                                         ; _cfDictionaryUnserialize+E4o ...
__const:[PII_REDACTED]053ED8                 dq offset _cfNumberUnserialize
__const:[PII_REDACTED]053EE0                 dq offset _cfBooleanUnserialize
__const:[PII_REDACTED]053EE8                 dq offset _cfArrayUnserialize
__const:[PII_REDACTED]053EF0                 dq offset _cfDictionaryUnserialize
__const:[PII_REDACTED]053EF8                 dq offset _cfDataUnserialize
__const:[PII_REDACTED]053F00                 dq offset _cfDateUnserialize
__const:[PII_REDACTED]053F08                 dq offset _cfURLUnserialize
__const:[PII_REDACTED]053F10                 dq offset _cfNullUnserialize
__const:[PII_REDACTED]053F18                 dq offset _cfAttributedStringUnserialize
__const:[PII_REDACTED]053F20                 dq offset _axElementUnserialize
__const:[PII_REDACTED]053F28                 dq offset _axValueUnserialize
__const:[PII_REDACTED]053F30                 dq offset _cgColorUnserialize
__const:[PII_REDACTED]053F38                 dq offset _axTextMarkerUnserialize
__const:[PII_REDACTED]053F40                 dq offset _axTextMarkerRangeUnserialize
__const:[PII_REDACTED]053F48                 dq offset _cgPathUnserialize

From a cursory inspection it's clear that these methods don't expect to parse untrusted data.

The first method, cfStringUnserialize, trusts the length field in the serialized representation
and uses that to byte-swap the string without any bounds checking leading to memory corruption.

I would guess that all the other unserialization methods should also be closely examined.

This poc talks to the com.apple.dock.server service hosted by the Dock process. Although this also
runs as the regular user (so doesn't represent much of a priv-esc) this same serialization mechanism
is also used in replies to dock clients.

com.apple.uninstalld is a client of the Dock and runs as root
so by first exploiting this bug to gain code execution as the Dock process, we could
trigger the same bug in uninstalld when it parses a reply from the dock and get code execution as root.

This poc just crashes the Dock process though.

Amusingly this opensource facebook code on github contains a workaround for a memory safety issue in cfAttributedStringUnserialize:
https://github.com/facebook/WebDriverAgent/pull/99/files

Tested on MacOS 10.12.3 (16D32)
*/

// ianbeer
#if 0
MacOS local EoP due to lack of bounds checking in HIServices custom CFObject serialization

HIServices.framework is used by a handful of deamons and implements its own CFObject serialization mechanism.

The entrypoint to the deserialization code is AXUnserializeCFType; it reads a type field and uses that
to index an array of function pointers for the support types:

__const:[PII_REDACTED]053ED0 _sUnserializeFunctions dq offset _cfStringUnserialize
__const:[PII_REDACTED]053ED0                                         ; DATA XREF: _AXUnserializeCFType+7Co
__const:[PII_REDACTED]053ED0                                         ; _cfDictionaryUnserialize+E4o ...
__const:[PII_REDACTED]053ED8                 dq offset _cfNumberUnserialize
__const:[PII_REDACTED]053EE0                 dq offset _cfBooleanUnserialize
__const:[PII_REDACTED]053EE8                 dq offset _cfArrayUnserialize
__const:[PII_REDACTED]053EF0                 dq offset _cfDictionaryUnserialize
__const:[PII_REDACTED]053EF8                 dq offset _cfDataUnserialize
__const:[PII_REDACTED]053F00                 dq offset _cfDateUnserialize
__const:[PII_REDACTED]053F08                 dq offset _cfURLUnserialize
__const:[PII_REDACTED]053F10                 dq offset _cfNullUnserialize
__const:[PII_REDACTED]053F18                 dq offset _cfAttributedStringUnserialize
__const:[PII_REDACTED]053F20                 dq offset _axElementUnserialize
__const:[PII_REDACTED]053F28                 dq offset _axValueUnserialize
__const:[PII_REDACTED]053F30                 dq offset _cgColorUnserialize
__const:[PII_REDACTED]053F38                 dq offset _axTextMarkerUnserialize
__const:[PII_REDACTED]053F40                 dq offset _axTextMarkerRangeUnserialize
__const:[PII_REDACTED]053F48                 dq offset _cgPathUnserialize

From a cursory inspection it's clear that these methods don't expect to parse untrusted data.

The first method, cfStringUnserialize, trusts the length field in the serialized representation
and uses that to byte-swap the string without any bounds checking leading to memory corruption.

I would guess that all the other unserialization methods should also be closely examined.

This poc talks to the com.apple.dock.server service hosted by the Dock process. Although this also
runs as the regular user (so doesn't represent much of a priv-esc) this same serialization mechanism
is also used in replies to dock clients.

com.apple.uninstalld is a client of the Dock and runs as root
so by first exploiting this bug to gain code execution as the Dock process, we could
trigger the same bug in uninstalld when it parses a reply from the dock and get code execution as root.

This poc just crashes the Dock process though.

Amusingly this opensource facebook code on github contains a workaround for a memory safety issue in cfAttributedStringUnserialize:
https://github.com/facebook/WebDriverAgent/pull/99/files

Tested on MacOS 10.12.3 (16D32)
#endif

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <mach/mach.h>
#include <mach/mess