Introduction Este post de blog é a segunda e última parte da nossa pesquisa da Avast e focará na exploração de CVE-2025-13032, uma vulnerabilidade de double-fetch que descobrimos no driver kernel da Avast. Esta postagem recapitula o bug e percorre como o exploramos em um sistema Windows 11 atualizado no momento do descobrimento. Sinta-se à vontade para ler a primeira parte se perdeu → https://www.safateam.com/intelligence-hub/research/technical-articles/cve-2025-13032-entering-and-breaking-the-avast-antivirus-sandbox-part-1

Bug Explanation O bug que queremos explorar é um double-fetch que leva a um overflow pool kernel. O snippet de código apresentado abaixo supostamente capturar uma estrutura `_UNICODE_STRING` fornecida pelo usuário, mas o campo `Length` da entrada do usuário é obtido múltiplas vezes, resultando em um problema de double-fetch. A primeira obtenção é feita para alocar um buffer onde a string será copiada, e a segunda obtenção é feita para realizar um memcpy baseado no valor recuperado, resultando em um overflow pool se o usuário mudar entre essas ações. Para explorar o double-fetch, um segundo thread roda em um loop apertado, alterando continuamente o campo `Length` do `_UNICODE_STRING` compartilhado entre um valor pequeno e seguro e um valor grande malicioso (por exemplo, `0x1000`, maior que o buffer alocado). O thread principal chama o IOCTL vulnerável em um loop. Quando o tempo se alinha — o kernel lê `Length` como pequeno para a chamada `ExAllocatePoolWithTag`, então lê como grande para o `memmove` — mais bytes são copiados do que foram alocados, produzindo o overflow pool. A janela de corrida é estreita mas pode ser ganha confiavelmente dentro de um número modesto de iterações. Nosso objetivo é explorar este overflow pool para obter um primitivo de leitura/escrita arbitrária de kernel e alcançar uma elevação de privilégios local. O bug nos dá boas condições de exploração: o overflow aponta para `PAGED_POOL`, tanto o tamanho da alocação quanto o tamanho do overflow estão controlados, assim como o conteúdo. Paged Pool é uma região de memória kernel do Windows usada para objetos e dados que o kernel ou os drivers precisam, mas que podem ser paginados para o disco. É usado para memória que não precisa ser acessada por código crítico executando com alta prioridade. O alocador agrupa alocações por classe de tamanho, o que significa que objetos do mesmo tamanho tendem a ficar próximos um do outro na memória — a propriedade que torna o spraying de pool viável. Desde o Windows 10 19H1 isso é tratado pelo Segment Heap, que usa dois backends: o LFH para pequenas alocações, que escolhe slots livres aleatoriamente dentro de um tamanho bucket, e o VS allocator para os maiores, que serve o primeiro bloco disponível do tamanho certo — cada um exigindo uma estratégia de spraying diferente. Também podemos notar que a maioria dos objetos Windows são armazenados no paged ...