zerozenxlabs/cve-2023-36424Windows-Kernel-Pool-Korruption (clfs.sys) – Privilegienerweiterung
==============
Windows-Kernel-Pool (clfs.sys) Korruption – Privilegieneskalation. (CVE-2023-36424)
Dieses Repo enthält eine technische Analyse und einen funktionierenden Exploit.
Autor: Nassim Asrir (@p1k4l4) || https://www.linkedin.com/in/nassim-asrir-b73a57122/
================
Im Minifilter-Treiber clfs.sys gibt es einen Pool-Überlauf. Informationen dazu können unter folgenden Links gelesen werden:
1 - https://googleprojectzero.blogspot.com/2021/01/hunting-for-bugs-in-windows-mini-filter.html
2 - https://www.zerodayinitiative.com/blog/2021/7/19/cve-2021-31969-underflowing-in-the-clouds
Der Grund ist, dass der Treiber Daten, die von einem NTFS-Reparse-Punkt stammen, nicht ausreichend prüft.
Wir betrachten clfs.sys Version 10.0.22621.2134 (Windows 11 22H2 22621.2215).
Die Funktion HsmFltProcessHSMControl ist für die Verarbeitung von Cloud-Filter-FSCTLs verantwortlich. Bei einer Operation mit dem Code 0xC0000003 ruft sie schließlich HsmFltProcessUpdatePlaceholder auf.
Nach einigen Verarbeitungsschritten erreicht der Ausführungsfluss HsmiOpUpdatePlaceholderDirectory und schließlich HsmpRpCommitNoLock:
__int64 __fastcall HsmpRpCommitNoLock(__int64 a1, __int64 a2, struct _FILE_OBJECT *a3, char a4, char a5)
{ .....
v26 = FileObject; LODWORD(v9) = HsmpRpReadBuffer(*(PFLT_INSTANCE *)(v164 + 32), FileObject, (unsigned __int16 **)&P); // [1*]
HsmDbgBreakOnStatus((unsigned int)v9);
if ( (_DWORD)v9 == -1073741195 ) .....
goto LABEL_55; }
if ( (v9 & 0x80000000) != 0i64 )
goto LABEL_9;}
if ( (*(_DWORD *)P & 0xFFFF0FFF) != dword_1C0027650 )// Is
Cloud Reparse Tag?
{
LODWORD(v9) = 0xC000CF0B;
.....
goto LABEL_54;
}
v32 = *((unsigned __int16 *)P + 2);
v9 = (unsigned int)HsmpRpValidateBuffer((__int64)P + 8, v32); [2*]
.....
Pool2 = ExAllocatePool2(0x100i64, 0x4000i64, 'pRsH'); // [3*]
v146 = (_DWORD *)Pool2;
v13 = (void *)Pool2;
if ( Pool2 )
{
v64 = v159_10;
v65 = Pool2 + 4;
if ( v8 && *((_WORD *)v8 + 7) > 0xAu )
v64 = *((_WORD *)v8 + 7);
v9 = Pool2 + 20;
v66 = (unsigned int *)(Pool2 + 12);
*(_OWORD *)v65 = 0i64;
*(_WORD *)(Pool2 + 16) = 0;
*(_WORD *)(Pool2 + 18) = v64;
*(_DWORD *)(Pool2 + 12) = 8 * v64 + 16;
*(_DWORD *)v65 = 'pReF';
memset((void *)(Pool2 + 20), 0, 8i64 * v64);
.....
if ( v8 )
{
v127 = 10;
if ( *((_WORD *)v8 + 7) > 0xAu ) // [4*]
{
if ( WPP_GLOBAL_Control !=
(PDEVICE_OBJECT)&WPP_GLOBAL_Control
&& (HIDWORD(WPP_GLOBAL_Control->Timer) & 1) != 0
&& BYTE1(WPP_GLOBAL_Control->Timer) >= 4u )
{
WPP_SF_qiq(WPP_GLOBAL_Control->AttachedDevice, v86,
v87, a2, *(_QWORD *)(v156 + 32), FileObject);
}
while ( v127 < *((_WORD *)v8 + 7) )
{
*(_QWORD *)(v65 + 8i64 * v127 + 16) = *(_QWORD
*)&v8[8 * v127 + 16];
memmove(
(void *)(v65 + *v66),
&v8[*(unsigned int *)&v8[8 * v127 + 20]],
*(unsigned __int16 *)&v8[8 * v127 + 18]); //
[5*]
*(_DWORD *)(v65 + 8i64 * v127 + 20) = *v66;
*v66 += *(unsigned __int16 *)(v65 + 8i64 * v127++ +
18);
}
}
}
.....
}
HsmpRpReadBuffer [1*] ruft die Daten des Reparse-Punkts ab. Diese Daten enthalten einen WORD-großen Wert *((_WORD *)v8 + 7), der eine Anzahl strukturierter Elemente angibt. Jedes Element hat ein Typ-Feld, eine Größe und einen Offset zu den Datenfeldern.
Welcher Elementtyp sich an welcher Stelle befindet, ist streng vorgegeben. Allerdings nur für die ersten 10. Beispielsweise muss das Typ-Feld des ersten Elements den Wert 0x7 haben.
Der Treiber führt HsmpRpValidateBuffer [2*] aus, um die abgerufenen Daten zu verifizieren. Dann wird [3*] ein auslagerbarer Pool (Paged Pool) mit einer festen Größe von 0x4000 Bytes alloziert. Und wenn die Reparse-Punkt-Daten einen Count-Wert von mehr als 10 haben, werden die Daten der Elemente nach dem zehnten ohne zusätzliche Prüfungen in diesen Pool mit fester Größe [4*] kopiert.
Die Validierung in HsmpRpValidateBuffer ist unzureichend, da nur die ersten 10 Datensätze geprüft werden.
__int64 __fastcall HsmpRpValidateBuffer(__int64 pBuf, unsigned int a2)
{
.....
v2 = a2 - 4;
pBuf2 = pBuf + 4;
LOBYTE(v5) = 0;
v6 = 0i64;
if ( a2 <= 4 )
v2 = 0;
v7 = 0;
v8 = *(_DWORD *)pBuf & 0xF;
if ( !v8 )
{
.....
return IsReparseBufferSupported;
}
if ( v8 > 1 )
{
....
}
v9 = 0;
v66 = 0;
if ( v2 < 0x18 )
goto ERROR_EXIT;
v9 = 1;
if ( *(_DWORD *)pBuf2 != 'pReF' )
goto ERROR_EXIT;
v9 = 2;
v10 = (unsigned int *)(pBuf + 0xC);
if ( (*(_BYTE *)(pBuf + 16) & 2) != 0 && *(_DWORD *)(pBuf +
8) != RtlComputeCrc32(0, (PUCHAR)(pBuf + 0xC), v2 - 8) )
goto ERROR_EXIT;
v11 = *v10;
v9 = 3;
if ( v2 < (unsigned int)v11 )
goto ERROR_EXIT;
v12 = *(unsigned __int16 *)(pBuf2 + 0xE);
v9 = 4;
if ( !(_WORD)v12 )
goto ERROR_EXIT;
v13 = 8 * v12 + 16;
v9 = 5;
if ( v13 >= v11 )
goto ERROR_EXIT;
v9 = 0x10000;
for ( i = 0; ; ++i )
{
v15 = *(unsigned __int16 *)(pBuf2 + 0xE);
if ( (unsigned int)v12 >= 0xA ) // [1*]
v15 = 10;
if ( i >= v15 )
break;
}
Wie wir bei [1*] sehen können, verifiziert der Code nur die ersten 10 Elemente und ignoriert den Fall, dass es weitere Datensätze gibt.
=================
Die Größe des verwundbaren Pools beträgt 0x4000. Die Größe ist ein Vielfaches einer Seite, daher wird die Segment-Allokation [3] verwendet.
Zur Ausnutzung wurde die hier [4] beschriebene Technik verwendet. Der Aufruf von NtAlpcCreateResourceReserve erzeugt viele Handles, und das Überschreiben eines davon mit dem Zeiger auf ein konstruiertes gefälschtes _KALPC_RESERVE-Objekt gibt uns die Möglichkeit, an beliebige Kernel-Adressen zu schreiben.
Um den Speicher vorzubereiten, allozieren wir nacheinander Pools der Größe 0x4000 mithilfe von Pipes [5]. Anschließend geben wir jeden zweiten Pool frei, um Platz für den verwundbaren Puffer zu schaffen.
Um eine beliebige Kernel-Adresse zu lesen, nutzt der Exploit Pipes. Zu diesem Zweck überschreiben wir den AttributeValue-Zeiger der PipeAttribute-Struktur.
Danach können wir das System-Token stehlen, um das Token im Zielprozess zu überschreiben.
Danke fürs Lesen.