Introduction Blog ini adalah bagian kedua dan terakhir dari penelitian kami tentang Avast dan akan fokus pada eksploitasi CVE-2025-13032, kerentanan double-fetch yang kita temukan di driver kernel Avast. Posting ini merekap bug dan membahas cara kita mengeksploitakannya pada sistem Windows 11 yang diperbarui pada saat temuan. Jika Anda melewatkan bagian pertama → https://www.safateam.com/intelligence-hub/research/technical-articles/cve-2025-13032-entering-and-breaking-the-avast-antivirus-sandbox-part-1

Bug Explanation Bug yang ingin kita eksploitasi adalah double-fetch yang menyebabkan kernel pool overflow. Kode snippet yang ditampilkan di bawah ini seharusnya menangkap struktur `_UNICODE_STRING` yang disediakan pengguna, tetapi field `Length` input pengguna diambil berulang kali, yang mengakibatkan double-fetch issue. Fetch pertama dilakukan untuk mengalokasikan buffer di mana string akan disalin, dan fetch kedua dilakukan untuk melakukan memcpy berdasarkan nilai yang didapat, yang mengakibatkan kernel pool overflow jika pengguna mengubahnya antara dua tindakan tersebut. Untuk mengeksploitasi double-fetch, thread kedua berjalan dalam loop ketat, terus-menerus mengubah field `Length` _UNICODE_STRING bersama antara nilai kecil yang aman dan nilai besar yang berbahaya (misalnya `0x1000`, lebih besar dari buffer yang dialokasikan). Thread utama memanggil IOCTL rentan dalam loop. Ketika waktu selaras — kernel membaca Length sebagai kecil untuk pemanggilan ExAllocatePoolWithTag, lalu membaca sebagai besar untuk memmove — lebih banyak byte yang disalin daripada yang dialokasi, menghasilkan kernel pool overflow. Jendela saing sempit tapi dapat dipercaya dalam jumlah iterasi yang moderat. Tujuan kita adalah mengeksploitasi kernel pool overflow ini untuk mendapatkan arbitrary kernel read/write primitive dan mencapai escalasi privilegium lokal. Bug ini memberikan kondisi eksploitasi yang bagus: overflow menargetkan PAGED_POOL, baik ukuran alokasi maupun ukuran overflow dikontrol, serta isi kontennya. Paged Pool adalah region memori kernel Windows yang digunakan untuk objek dan data yang diperlukan kernel atau driver, tetapi yang dapat dipindah ke disk. Digunakan untuk memori yang tidak perlu diakses kode kritis yang berjalan dengan prioritas tinggi. The allocator groups allocations by size class, meaning same-sized objects tend to land close to each other in memory — the property that makes heap spraying viable. Since Windows 10 19H1 this is handled by the Segment Heap, which uses two backends: the LFH for small allocations, which picks free slots randomly within a size bucket, and the VS allocator for larger ones, which serves the first available chunk of the right size — each requiring a different spray strategy. We can also note that most Windows objects are stored in the paged ...