CVE-2024-6768: Improper validation of specified quantity in input produces an unrecoverable state in CLFS.sys causing a BSoD.
CVE-2024-6768 is a vulnerability in the Common Log File System (CLFS.sys) driver of Windows, caused by improper validation of specified quantities in input data. This flaw leads to an unrecoverable inconsistency, triggering the KeBugCheckEx function and resulting in a Blue Screen of Death (BSoD). The issue affects all versions of Windows 10 and Windows 11, Windows Server 2016, Server 2019 and Server 2022 despite having all updates applied. A Proof of Concept (PoC) shows that by crafting specific values within a .BLF file, an unprivileged user can induce a system crash. The potential problems include system instability and denial of service, as malicious users can exploit this vulnerability to repeatedly crash affected systems, disrupting operations and potentially causing data loss.
In the last two research endeavors on Common Log File System (CLFS), I was able to achieve RCE in both cases. (If you are interested here is the one I did for CLFS CVE-2023-28252 and CLFS CVE-2022-37969). However, when I modified some values in the PoC I was working on, I observed that it triggered a BSoD on the target system. Consequently, I decided to report this issue. This document helps to understand the BSoD and provides guidance on how to reproduce it.
This vulnerability is produced by an Improper Validation of Specified Quantity in Input (CWE-1284)
which causes an unrecoverable inconsistency in the CLFS.sys driver, forcing a call to the KeBugCheckEx function, which allows an unprivileged user to produce a BSoD in Windows. In this document, I’m using CLFS.sys version 10.0.19041.3324 as an example, but this issue is affecting all versions up to the latest version of Windows 10 and Windows 11 with all updates applied.
Base Score: CVSS 4.0: 6.8 Medium
Vector String CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Attack Vector (AV): Local
Attack Complexity (AC): Low
Attack Requirements (AT): None
Privileges Required (PR): Low
User Interaction (UI): None
Confidentiality (VC): None
Integrity (VI): None
Availability (VA): High
Confidentiality (SC): None
Integrity (SI): None
Availability (SA): None
After the system detects the unrecoverable state, it calls the KeBugCheckEx function which leads to a BSoD as described by Microsoft in this article: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-kebugcheckex.
CClfsLogFcbPhysical::FlushLog+6F2 is the address in CLFS.sys version 10.0.19041.3324 where the call to KeBugCheckEx is produced:
CClfsLogFcbPhysical::FlushLog+6D5
CClfsLogFcbPhysical::FlushLog+6D5 loc_FFFFF8062EED4F35: ; BugCheckParameter2
CClfsLogFcbPhysical::FlushLog+6D5 mov r8d, eax
CClfsLogFcbPhysical::FlushLog+6D8 and [rsp+0A8h+Timeout], 0
CClfsLogFcbPhysical::FlushLog+6DE mov r9, rbx ; BugCheckParameter3
CClfsLogFcbPhysical::FlushLog+6E1 mov edx, 3Ah ; ':' ; BugCheckParameter1
CClfsLogFcbPhysical::FlushLog+6E6 mov ecx, 0C1F5h ; BugCheckCode
CClfsLogFcbPhysical::FlushLog+6EB mov r10, cs:__imp_KeBugCheckEx
CClfsLogFcbPhysical::FlushLog+6F2 call near ptr nt_KeBugCheckEx
To begin the analysis, it’s necessary to know the .BLF file format, that is handled by the vulnerable Common Log File System driver called CLFS.sys located in folder %windir%\system32. To learn more about this, check the references section at the end of this article.
In our proof of concept repo, the 54.blf file has a crafted value (0xffffffff00ff01) in offset 0x1c10.
This crafted value is in offset 0x38 of the _CLFS_CLIENT_CONTEXT structure, it is copied in CClfsLogFcbPhysical::Initialize to 0x538 offset of CClfsLogFcbPhysical structure.
The below blue marked zone starts with cidNode = 0xC1FDF006 is the CLFSHASHSYM structure
After that starting with cidNode == 0xC1FDF007 is located the _CLFS_CLIENT_CONTEXT structure
In offset 0x38 is the field lsnOwnerPage which will be filled with the crafted value 0xffffffff00ff01:
struct _CLFS_CLIENT_CONTEXT
{
CLFS_NODE_ID cidNode;
CLFS_CLIENT_ID cidClient;
USHORT fAttributes;
ULONG cbFlushThreshold;
ULONG cShadowSectors;
ULONGLONG cbUndoCommitment;
LARGE_INTEGER llCreateTime;
LARGE_INTEGER llAccessTime;
LARGE_INTEGER llWriteTime;
*CLFS_LSN **lsnOwnerPage; ***// offset 0x38
CLFS_LSN lsnArchiveTail;
CLFS_LSN lsnBase;
CLFS_LSN lsnLast;
CLFS_LSN lsnRestart;
CLFS_LSN lsnPhysicalBase;
CLFS_LSN lsnUnused1;
CLFS_LSN lsnUnused2;
CLFS_LOG_STATE eState;
union
{
HANDLE hSecurityContext;
ULONGLONG ullAlignment;
};
};
When the PoC is executed, it crafts the value of lsnOwnerPage, calls CreateLogFile and the mentioned value is used in UpdateCachedOwnerPage as seen in the call stack below:
This is the address where the PoC calls to the CreateLogFile and the crafted value starts to be used:
Inside AddLsnOffset returns an ulloffset calculated from this crafted value:
The returned ulloffset is 0xFFFFFFFF00000000
After that, this value is compared and exits the function CClfsLogFcbPhysical::UpdateCachedOwnerPage
After that, it returns to the PoC in user mode, and when it exits it calls CClfsLogFcbPhysical::FlushLog when the original crafted ullofset is used
This is compared in a loop and, if is not equal in any cycle, as the system is in unrecoverable state, it calls to KeBugCheck that produces a BSoD to restart itself:
You can find the functional PoC with sources and crafted BLF at Fortra’s GitHub.
I hope you find it useful. Please contact [email protected] with any questions.
Common Log File System (CLFS) references: