Introduction Cet article de blog est la deuxième et dernière partie de nos recherches Avast et se concentrera sur l'exploitation de CVE-2025-13032, une vulnérabilité de double lecture découverte dans le pilote kernel d'Avast. Cette publication recapote l'erreur et nous explique comment nous l'avons exploitée sur un système Windows 11 à jour au moment de la découverte. N'hésitez pas à lire la première partie si vous l'avez manquée → https://www.safateam.com/intelligence-hub/research/technical-articles/cve-2025-13032-entering-and-breaking-the-avast-antivirus-sandbox-part-1

Bug Explanation L'erreur que nous voulons exploiter est une vulnérabilité de double lecture entraînant un débordement pool kernel. Extrait de code présenté ci-dessous est supposé capturer une structure `_UNICODE_STRING` fournie par l'utilisateur, mais le champ `Length` de l'entrée utilisateur est récupéré plusieurs fois, ce qui entraîne un problème de double lecture. La première récupération est effectuée pour allouer un tampon où la chaîne sera copiée, et la deuxième récupération est effectuée pour effectuer un memcpy en se basant sur la valeur récupérée, ce qui entraîne un débordement pool si l'utilisateur change entre ces actions. Pour exploiter la double lecture, un deuxième thread s'exécute dans une boucle serrée, basculant continuellement le champ `Length` du `_UNICODE_STRING` partagé entre une valeur petite et sûre et une valeur grande malveillante (par exemple `0x1000`, plus grande que le tampon alloué). Le thread principal appelle l'IOCTL vulnérable en boucle. Lorsque le timing s'aligne — le kernel lit `Length` comme petit pour l'appel `ExAllocatePoolWithTag`, puis lit comme grand pour le `memmove` — plus de bytes sont copiés que ceux qui étaient alloués, produisant le débordement pool. La fenêtre de compétition est étroite mais peut être gagnée fiablement dans un nombre modéré d'itérations. Notre but est d'exploiter ce débordement pool pour obtenir un primitif lecture/écriture arbitraire de kernel et réaliser une élévation de privilèges locale. L'erreur nous donne de bonnes conditions d'exploitation : le débordement cible `PAGED_POOL`, à la fois la taille d'allocation et la taille du débordement sont contrôlées, tout comme le contenu. Paged Pool est une région de mémoire kernel Windows utilisée pour les objets et les données que le kernel ou les pilotes ont besoin, mais qui peuvent être paginées sur disque. Elle est utilisée pour la mémoire qui n'a pas besoin d'être accédée par un code critique s'exécutant avec une priorité élevée. L'alloueur regroupe les allocations par classe de taille, ce qui signifie que les objets de même taille ont tendance à atterrir près les uns des autres en mémoire — la propriété qui rend le spraying de pool viable. Depuis Windows 10 19H1, cela est géré par le Segment Heap, qui utilise deux backends : le LFH pour les petites allocations, qui choisit des créneaux libres au hasard dans une taille seau, et le VS allocator pour les plus grands, qui sert le premier bloc disponible de la bonne taille — chaque stratégie nécessitant une approche de spraying différente. Nous pouvons également noter que la plupart des objets Windows sont stockés dans le paged ...