## https://sploitus.com/exploit?id=F9437749-2ECA-516E-B17F-0702521A75AE
# CVE-2024-6768: Improper validation of specified quantity in input produces an unrecoverable state in CLFS.sys causing a BSoD.
# Introduction:
[CVE-2024-6768](https://vulners.com/cve/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](https://www.coresecurity.com/core-labs/articles/analysis-cve-2023-28252-clfs-vulnerability)
and CLFS
[CVE-2022-37969](https://www.coresecurity.com/core-labs/articles/understanding-cve-2022-37969-windows-clfs-lpe)).
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](https://cwe.mitre.org/data/definitions/1284.html))
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**
# Building 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](https://github.com/fortra/CVE-2024-6768),
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.
- <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 it useful. Please contact
<vulnerability.disclosure@fortra.com> 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://vulners.com/cve/CVE-2024-6768>