Introduction
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 (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.
Vulnerability Details
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 in an article by Microsoft.
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_KeBugCheckExBuilding the PoC
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 offset 0x538 of the CClfsLogFcbPhysical structure.
The CLFSHASHSYM structure starts with cidNode = 0xC1FDF006 and is highlighted in blue:
After that, the _CLFS_CLIENT_CONTEXT structure begins with cidNode == 0xC1FDF007.
The field lsnOwnerPage is in offset 0x38, which will be filled with the crafted value 0xffffffff00ff01:
When the PoC is executed, it crafts the value of lsnOwnerPage and calls CreateLogFile. The mentioned value is used in UpdateCachedOwnerPage, as seen in the call stack below:
This is the address where the PoC calls the CreateLogFile and the crafted value starts to be used:
An ulloffset returns inside AddLsnOffset, 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, which produces a BSoD to restart itself:
You can find the functional PoC with sources and crafted BLF at Fortra’s GitHub:
- https://github.com/fortra/CVE-2024-6768
- https://github.com/fortra/CVE-2024-6768/blob/main/clfs_eopNEW/x64/Release/clfs_eop.exe
I hope you find this useful. Please contact [email protected] with any questions.
References
Common Log File System (CLFS) references:
- https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part
- https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-the-common-log-file-system
- https://github.com/ionescu007/clfs-docs/blob/main/README.md
- https://www.coresecurity.com/core-labs/articles/understanding-cve-2022-37969-windows-clfs-lpe
- https://www.youtube.com/watch?v=N5bcibiDVaw
- https://github.com/fortra/CVE-2024-6768
- https://www.fortra.com/security/advisories/research/fr-2024-001
- https://www.cve.org/CVERecord?id=CVE-2024-6768
