fortra/cve-2024-6768
CVE-2024-6768 è una vulnerabilità nel driver del Common Log File System (CLFS.sys) di Windows, causata da una validazione impropria delle quantità specificate nei dati di input. Questo difetto porta a un'incoerenza irreversibile, attivando la funzione KeBugCheckEx e provocando un Blue Screen of Death (BSoD). Il problema interessa tutte le versioni di Windows 10 e Windows 11, Windows Server 2016, Server 2019 e Server 2022 anche con tutti gli aggiornamenti applicati. Un Proof of Concept (PoC) mostra che, creando valori specifici all'interno di un file .BLF, un utente senza privilegi può indurre un arresto anomalo del sistema. I potenziali problemi includono instabilità del sistema e denial of service, poiché utenti malintenzionati possono sfruttare questa vulnerabilità per mandare in crash ripetutamente i sistemi interessati, interrompendo le operazioni e potenzialmente causando perdita di dati.
Negli ultimi due progetti di ricerca su Common Log File System (CLFS), sono riuscito a ottenere RCE in entrambi i casi. (Se siete interessati, ecco quello che ho realizzato per CLFS CVE-2023-28252 e CLFS CVE-2022-37969). Tuttavia, quando ho modificato alcuni valori nel PoC su cui stavo lavorando, ho osservato che provocava un BSoD sul sistema di destinazione. Di conseguenza, ho deciso di segnalare il problema. Questo documento aiuta a comprendere il BSoD e fornisce indicazioni su come riprodurlo.
Questa vulnerabilità è prodotta da una validazione impropria della quantità specificata nell'input (CWE-1284)
che causa un'incoerenza irreversibile nel driver CLFS.sys, forzando una chiamata alla funzione KeBugCheckEx funzione, che consente a un utente senza privilegi di provocare un BSoD in Windows. In questo documento, uso CLFS.sys versione 10.0.19041.3324 come esempio, ma il problema interessa tutte le versioni fino all'ultima di Windows 10 e Windows 11 con tutti gli aggiornamenti applicati.
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
Dopo che il sistema rileva lo stato irreversibile, chiama la funzione KeBugCheckEx, che porta a un BSoD come descritto da Microsoft in questo articolo: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-kebugcheckex.
CClfsLogFcbPhysical::FlushLog+6F2 è l'indirizzo nella versione CLFS.sys 10.0.19041.3324 in cui viene effettuata la chiamata a KeBugCheckEx:
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
Per iniziare l'analisi, è necessario conoscere il formato del file .BLF, gestito dal driver vulnerabile Common Log File System chiamato CLFS.sys situato nella cartella %windir%\system32. Per saperne di più, consultare la sezione dei riferimenti alla fine di questo articolo.
Nel nostro repository proof of concept, il file 54.blf contiene un valore modificato (0xffffffff00ff01) all'offset 0x1c10.
Questo valore modificato si trova all'offset 0x38 della struttura _CLFS_CLIENT_CONTEXT; viene copiato in CClfsLogFcbPhysical::Initialize all'offset 0x538 della struttura CClfsLogFcbPhysical.
La zona evidenziata in blu di seguito inizia con cidNode = 0xC1FDF006 ed è la struttura CLFSHASHSYM
Dopo di che, a partire da cidNode == 0xC1FDF007, si trova la struttura _CLFS_CLIENT_CONTEXT
All'offset 0x38 si trova il campo lsnOwnerPage, che verrà riempito con il valore modificato 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 il PoC viene eseguito, modifica il valore di lsnOwnerPage, chiama CreateLogFile e il valore menzionato viene usato in UpdateCachedOwnerPage come si vede nello stack di chiamate qui sotto:
Questo è l'indirizzo in cui il PoC chiama CreateLogFile e il valore modificato inizia a essere usato:
All'interno di AddLsnOffset viene restituito un ulloffset calcolato da questo valore modificato:
L'ulloffset restituito è 0xFFFFFFFF00000000
Dopodiché, questo valore viene confrontato e la funzione CClfsLogFcbPhysical::UpdateCachedOwnerPage termina
Dopodiché, si ritorna al PoC in modalità utente e, quando termina, viene chiamata CClfsLogFcbPhysical::FlushLog quando viene usato il ullofset originale modificato
Questo viene confrontato in un ciclo e, se non è uguale in nessuna iterazione, dato che il sistema si trova in uno stato irreversibile, viene chiamata KeBugCheck che produce un BSoD per riavviare il sistema:
Puoi trovare il PoC funzionante con i sorgenti e il BLF modificato sul GitHub di Fortra.
Spero che lo troviate utile. Per qualsiasi domanda, contattate [email protected].
Riferimenti su Common Log File System (CLFS):
