EDB-ID: 42056 | Author: Google Security Research | Published: 2017-05-23 | CVE: CVE-2017-6978 | Type: Dos | Platform: macOS | Aliases: N/A | Advisory/Source: Link | Tags: N/A | Vulnerable App: N/A | 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:0000000000053ED0 _sUnserializeFunctions dq offset _cfStringUnserialize
__const:0000000000053ED0 ; DATA XREF: _AXUnserializeCFType+7Co
__const:0000000000053ED0 ; _cfDictionaryUnserialize+E4o ...
__const:0000000000053ED8 dq offset _cfNumberUnserialize
__const:0000000000053EE0 dq offset _cfBooleanUnserialize
__const:0000000000053EE8 dq offset _cfArrayUnserialize
__const:0000000000053EF0 dq offset _cfDictionaryUnserialize
__const:0000000000053EF8 dq offset _cfDataUnserialize
__const:0000000000053F00 dq offset _cfDateUnserialize
__const:0000000000053F08 dq offset _cfURLUnserialize
__const:0000000000053F10 dq offset _cfNullUnserialize
__const:0000000000053F18 dq offset _cfAttributedStringUnserialize
__const:0000000000053F20 dq offset _axElementUnserialize
__const:0000000000053F28 dq offset _axValueUnserialize
__const:0000000000053F30 dq offset _cgColorUnserialize
__const:0000000000053F38 dq offset _axTextMarkerUnserialize
__const:0000000000053F40 dq offset _axTextMarkerRangeUnserialize
__const:0000000000053F48 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:0000000000053ED0 _sUnserializeFunctions dq offset _cfStringUnserialize
__const:0000000000053ED0 ; DATA XREF: _AXUnserializeCFType+7Co
__const:0000000000053ED0 ; _cfDictionaryUnserialize+E4o ...
__const:0000000000053ED8 dq offset _cfNumberUnserialize
__const:0000000000053EE0 dq offset _cfBooleanUnserialize
__const:0000000000053EE8 dq offset _cfArrayUnserialize
__const:0000000000053EF0 dq offset _cfDictionaryUnserialize
__const:0000000000053EF8 dq offset _cfDataUnserialize
__const:0000000000053F00 dq offset _cfDateUnserialize
__const:0000000000053F08 dq offset _cfURLUnserialize
__const:0000000000053F10 dq offset _cfNullUnserialize
__const:0000000000053F18 dq offset _cfAttributedStringUnserialize
__const:0000000000053F20 dq offset _axElementUnserialize
__const:0000000000053F28 dq offset _axValueUnserialize
__const:0000000000053F30 dq offset _cgColorUnserialize
__const:0000000000053F38 dq offset _axTextMarkerUnserialize
__const:0000000000053F40 dq offset _axTextMarkerRangeUnserialize
__const:0000000000053F48 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)
