fortra/cve-2024-6768Exploit de prova de conceito para CVE-2024-6768, uma vulnerabilidade no driver Windows CLFS.sys que causa BSoD através de um arquivo .BLF manipulado. Inclui código-fonte e análise técnica.
CVE-2024-6768 é uma vulnerabilidade no driver Common Log File System (CLFS.sys) do Windows, causada pela validação inadequada de quantidades especificadas nos dados de entrada. Essa falha leva a uma inconsistência irrecuperável, acionando a função KeBugCheckEx e resultando em uma Tela Azul da Morte (BSoD). O problema afeta todas as versões do Windows 10 e Windows 11, Windows Server 2016, Server 2019 e Server 2022, mesmo com todas as atualizações aplicadas. Uma Prova de Conceito (PoC) mostra que, ao criar valores específicos em um arquivo .BLF, um usuário sem privilégios pode induzir uma falha no sistema. Os problemas potenciais incluem instabilidade do sistema e negação de serviço, já que usuários maliciosos podem explorar essa vulnerabilidade para travar repetidamente sistemas afetados, interrompendo operações e potencialmente causando perda de dados.
Nos últimos dois trabalhos de pesquisa sobre o Common Log File System (CLFS), consegui obter RCE em ambos os casos. (Se tiver interesse, aqui está o que fiz para CLFS CVE-2023-28252 e CLFS CVE-2022-37969). No entanto, quando modifiquei alguns valores na PoC em que estava trabalhando, observei que isso acionava um BSoD no sistema alvo. Consequentemente, decidi relatar esse problema. Este documento ajuda a entender o BSoD e fornece orientação sobre como reproduzi-lo.
Esta vulnerabilidade é produzida por uma Validação Inadequada de Quantidade Especificada na Entrada (CWE-1284) que causa uma inconsistência irrecuperável no driver CLFS.sys, forçando uma chamada à função KeBugCheckEx, o que permite a um usuário sem privilégios produzir um BSoD no Windows. Neste documento, estou usando a versão 10.0.19041.3324 do CLFS.sys como exemplo, mas este problema afeta todas as versões até a versão mais recente do Windows 10 e Windows 11 com todas as atualizações aplicadas.
Pontuação Base: CVSS 4.0: 6.8 Médio
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
Vetor de Ataque (AV): Local
Complexidade do Ataque (AC): Baixa
Requisitos de Ataque (AT): Nenhum
Privilégios Necessários (PR): Baixos
Interação do Usuário (UI): Nenhuma
Confidencialidade (VC): Nenhuma
Integridade (VI): Nenhuma
Disponibilidade (VA): Alta
Confidencialidade (SC): Nenhuma
Integridade (SI): Nenhuma
Disponibilidade (SA): Nenhuma
Após o sistema detectar o estado irrecuperável, ele chama a função KeBugCheckEx que leva a um BSoD conforme descrito pela Microsoft neste artigo: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-kebugcheckex.
CClfsLogFcbPhysical::FlushLog+6F2 é o endereço na versão 10.0.19041.3324 do CLFS.sys onde a chamada a KeBugCheckEx é produzida:
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
Para iniciar a análise, é necessário conhecer o formato do arquivo .BLF, que é manipulado pelo driver vulnerável do Common Log File System chamado CLFS.sys localizado na pasta %windir%\system32. Para saber mais sobre isso, consulte a seção de referências no final deste artigo.
No nosso repositório de prova de conceito, o arquivo 54.blf tem um valor manipulado (0xffffffff00ff01) no offset 0x1c10.
Este valor manipulado está no offset 0x38 da estrutura _CLFS_CLIENT_CONTEXT, é copiado em CClfsLogFcbPhysical::Initialize para o offset 0x538 da estrutura CClfsLogFcbPhysical.
A zona marcada em azul abaixo começa com cidNode = 0xC1FDF006 e é a estrutura CLFSHASHSYM
Depois disso, começando com cidNode == 0xC1FDF007, está localizada a estrutura _CLFS_CLIENT_CONTEXT
No offset 0x38 está o campo lsnOwnerPage que será preenchido com o valor manipulado 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; }; };
Quando a PoC é executada, ela manipula o valor de lsnOwnerPage, chama CreateLogFile e o valor mencionado é usado em UpdateCachedOwnerPage como visto na pilha de chamadas abaixo:
Este é o endereço onde a PoC chama CreateLogFile e o valor manipulado começa a ser usado:
Dentro de AddLsnOffset retorna um ulloffset calculado a partir deste valor manipulado:
O ulloffset retornado é 0xFFFFFFFF00000000
Depois disso, este valor é comparado e sai da função CClfsLogFcbPhysical::UpdateCachedOwnerPage
