CVE-2025-13032: Avast sürücüsündeki double-fetch hatası Windows 11'de kernel okuma/yazma imkânına dönüştürüldü

safateam.com'un teknik incelemesi, ekibin CVE-2025-13032 üzerine yaptığı iki bölümlük araştırmanın sonunu tamamlıyor. CVE-2025-13032, Avast antivirüsüyle birlikte gelen bir kernel sürücüsündeki double-fetch zafiyeti. İkinci yazı, hatanın bulunduğu dönemde tamamen güncel bir Windows 11 makinesinde nasıl sömürüldüğünü adım adım anlatıyor; küçük bir ayrıştırma hatası, kernel pool taşmasına ve oradan da yerel yetki yükseltmeye uygun bir keyfi kernel okuma/yazma ilkeline (primitive) dönüştürülüyor.

Hata: Tek bir uzunluk değeri, iki kez okunuyor

Yazıya göre sürücü, kullanıcı modundan _UNICODE_STRING yapısını kabul ediyor. Kernel tarafındaki kod önce kullanıcı tamponunun okunabilirliğini denetliyor, ardından yapının Length alanını okuyarak ExAllocatePoolWithTag ile yapılan bir PagedPool tahsisinin boyutunu belirliyor ve daha sonra aynı alana memmove işlemini yönlendirmek için ikinci kez bakıyor. İki okumayı uyumlu olmaya zorlayan hiçbir şey yok, çünkü kullanıcı belleği bu aralıklarda değiştirilebilir.

Yarışı kazanmak için ikinci bir kullanıcı modu thread'i, paylaşılan Length alanını küçük ve güvenli bir değer ile kötü niyetli bir değer (araştırmacılar 0x1000 kullanıyor) arasında sürekli döndürüyor; aynı anda ana thread savunmasız IOCTL'i yoğun biçimde çağırıyor. Kernel tahsis sırasında küçük değeri, kopyalama sırasında ise büyük değeri okursa, ayrılan alandan daha fazla bayt yazılıyor. Araştırmacılar, zamanlama penceresinin dar olmakla birlikte sınırlı sayıda denemeden sonra güvenilir biçimde yakalanabildiğini bildiriyor. Sömürü açısından kritik nokta, saldırganın tahsis boyutunu, taşma boyutunu ve taşan içeriği doğrudan kontrol edebilmesi.

Paged pool'da hedef seçimi

Taşma paged pool'da, yani diske takas edilebilen nesne ve veriler için kullanılan kernel bellek bölgesinde gerçekleştiği için araştırmacıların bozabileceği yapı seçeneği genişti. Windows 10 19H1'den bu yana pool'un Segment Heap tarafından yönetildiğini, küçük tahsislerin LFH arka ucu tarafından rastgele yuvalarda, daha büyüklerin ise VS arka ucu tarafından first-fit biçimde dağıtıldığını açıklıyorlar; dolayısıyla her boyut sınıfı kendi spray stratejisini gerektiriyor.

Seçtikleri hedef ise I/O Ring: kullanıcı modundan CreateIoRing, BuildIoRingRegisterBuffers ve SubmitIoRing gibi API'lerle asenkron dosya I/O işlemlerini toplu hâlde yürütmeyi sağlayan Windows özelliği. I/O Ring nesnesinin kendisi non-paged pool'da yaşasa da, tuttuğu kayıtlı tampon işaretçileri dizisi — _IORING_OBJECT içindeki RegBuffers — paged pool'da tahsis ediliyor ve taşmayla tam olarak örtüşüyor. N tampon kaydetmek, N adet sekiz baytlık işaretçiden oluşan bir dizi ürettiği için tahsis boyutu doğrudan kullanıcı kontrollü; bu da heap spray'i hassas hâle getiriyor. Üstelik kayıtlı tamponlar yalnızca kayıt sırasında denetleniyor ve sonraki IoRingReadFile ile IoRingWriteFile işlemlerinde güvenilir varsayılıyor; bu yüzden dizideki tek bir işaretçiyi bozmak, kernel okuma ve yazmalarını saldırganın seçtiği bir adrese yönlendirmek için yeterli. Ekip, aynı nesneyi Windows 11'de okuma/yazma ilkelini inşa etmek için kullanan, windows-internals.com'da yayımlanmış önceki bir araştırmaya atıf yapıyor; bu da yaklaşımı güvenmelerinden önce doğrulamıştı.

Zaten yayımlanmış bir önlem

Yazıda önemli bir uyarı da yer alıyor: yakın tarihli Windows sürümleri, kernel'da ve sürücülerde kullanıcı modu erişimcileri (user-mode accessor) benimsemiş durumda; kullanıcı işaretçileri daha önce yapılan bir denetime güvenmek yerine her kernel erişiminde kontrol ediliyor. Araştırmacılara göre bu sağlamlaştırma, yazılarında anlatılan sömürü tekniğini etkisiz kılıyor; dolayısıyla gösterilen yol, önlemden önceki bir Windows sürümü çalıştırmaya dayanıyor.

Neden önemli

Antivirüs ürünleri, tipik bir Windows makinesindeki en maruz kalmış kernel kodlarından bir kısmını kurar: güvenilmeyen, saldırgan tarafından sağlanan girdileri ayrıştırır ve sonuçları ayrıcalıklı sürücülere aktarırlar. Bu tür bir hata, o maruziyeti herhangi bir yerel hesaptan SYSTEM'a giden doğrudan bir yola çevirir; bu da kötü amaçlı yazılım operatörlerinin bir ilk ayak izi edindikten sonra tam olarak istediği şeydir. Yazı ayrıca, on yıldan uzun süredir belgelenmiş bir sınıf olan double-fetch kusurlarının, önlemler bulunmadığında çağdaş sistemlerde hâlâ pratik olduğunu gösteriyor ve performans için tasarlanmış işletim sistemi olanaklarının — I/O Ring'in kayıtlı tamponları gibi — kullanışlı sömürü ilkelleri olarak da işlev görebildiğini örnekliyor. Savunucular için çıkarım iki yönlü: güvenlik yazılımları, koruduğu işletim sistemiyle aynı titizlikle incelenmeyi hak eder ve kullanıcı modu erişimcileri gibi kernel sağlamlaştırmaları tekil hataları değil, bütün teknik kategorilerini emekliye ayırır.