Introduction Dieser Blogbeitrag ist die zweite und finale Partie unserer Avast-Forschung und wird sich auf die Exploitation von CVE-2025-13032 konzentrieren, einer Double-Fetch-Schwachstelle, die wir in Avast's Kernel-Treiber entdeckt haben. Dieser Beitrag fasst den Bug zusammen und führt durch die Exploitation an einem aktualisierten Windows 11 System zum Zeitpunkt der Entdeckung. Falls Sie den ersten Teil verpasst haben → https://www.safateam.com/intelligence-hub/research/technical-articles/cve-2025-13032-entering-and-breaking-the-avast-antivirus-sandbox-part-1

Bug Explanation Der Bug, den wir ausnutzen wollen, ist ein Double-Fetch-Problem, das zu einem Kernel-Pool-Overflow führt. Im nachstehenden Code-Snippet soll eine `_UNICODE_STRING`-Struktur erfasst werden, die vom Benutzer bereitgestellt wird, aber das `Length`-Feld der Benutzereingabe wird mehrmals abgeholt, was zu einem Double-Fetch-Problem führt. Die erste Abholung dient dazu, einen Buffer zu allozieren, in den der String kopiert wird, und die zweite Abholung dient dazu, basierend auf dem abgerufenen Wert einen memcpy durchzuführen, was bei einer Änderung zwischen diesen Aktionen seitens des Benutzers zu einem Pool-Overflow führt. Um den Double-Fetch auszunutzen, läuft ein zweiter Thread in einer engen Schleife, die kontinuierlich das `Length`-Feld des gemeinsam genutzten `_UNICODE_STRING` zwischen einem kleinen sicheren Wert und einem großen bösartigen Wert (z. B. `0x1000`, größer als dem allozierten Buffer) hin- und her schaltet. Der Hauptthread ruft die anfällige IOCTL in einer Schleife auf. Wenn die Timing stimmt — der Kernel liest `Length` als klein für den Aufruf `ExAllocatePoolWithTag`, dann liest er als groß für den `memmove` — werden mehr Bytes kopiert, als alloziert waren, was einen Pool-Overflow erzeugt. Der Race-Fenster ist schmal, kann aber innerhalb einer moderaten Anzahl an Iterationen zuverlässig gewonnen werden. Unser Ziel ist es, diesen Pool-Overflow auszunutzen, um einen arbitrary Kernel-Read/Write-Primitiv zu erhalten und eine lokale Privilegiensteigerung zu erreichen. Der Bug gibt uns gute Exploit-Bedingungen: das Overflow targetet `PAGED_POOL`, sowohl die Allokationsgröße als auch der Overflow-Betrag sind kontrolliert, und auch der Inhalt. Paged Pool ist ein Bereich des Windows-Kernel-Speichers, der für Objekte und Daten verwendet wird, die das Kernel oder Treiber benötigen, aber die nicht von kritischem Code mit hoher Priorität ausgeführt werden müssen. Der Allokator gruppiert Allokationen nach Größenklasse, was bedeutet, dass gleich große Objekte dazu neigen, nah beieinander im Speicher zu landen — die Eigenschaft, die das Pool-Spraying ermöglicht. Seit Windows 10 19H1 wird dies vom Segment Heap verwaltet, der zwei Backends verwendet: das LFH für kleine Allokationen, das frei Slots zufällig innerhalb einer Größenklasse auswählt, und den VS allocator für größere, der die erste verfügbare Chunk der richtigen Größe bereitstellt — jede erfordert eine unterschiedliche Spray-Strategie. Wir können auch feststellen, dass die meisten Windows-Objekte im paged ...