Skip to content

Secure Boot bypass via misused NVRAM variable (VU#806555, DTBios/BiosFlashShell)

Microsoft tarafından imzalı UEFI utility'leri (DTBios, BiosFlashShell), attacker'ın kontrol edebildiği bir NVRAM variable'ını memory pointer olarak okuyor ve global Secure Boot enforcement pointer'ını (gSecurity2) üzerine yazan bir arbitrary write veriyor.

Canonical note

Bu, CVE-2025-3052 = VU#806555 için canonical (tam) yazımdır. secure-boot-bypass-via-signed-uefi-app-nvram-write aynı bug'ı tanımlar ve buraya redirect eden bir stub'tır (alias_of).

Mechanism

Note

Secure Boot enforcement tek bir firmware yapısı üzerinden akıtılır: global pointer gSecurity2 üzerinden ulaşılan Security2 Architectural Protocol. Her image-authentication kararı (FileAuthentication) bunun üzerinden geçer. Bir attacker o pointer'a yazabilirse — onu daima "authorized" dönen bir stub'a yönlendirerek veya kontrolü null'layarak — Secure Boot, boot'un geri kalanı için fiilen kapatılmış olur.

VU#806555 — kataloglanmış olarak CVE-2025-3052 (Binarly advisory BRLY-DVA-2025-001) — IhisiParamBuffer adlı bir NVRAM variable'ının içeriğine güvenen ve değerini memory operasyonları için bir pointer olarak kullanan UEFI uygulamalarını (DTResearch'ün DTBios ve BiosFlashShell'i, bir AMI türevi BIOS-flashing utility) anlatıyor. Runtime NVRAM variable'ları kilitli olmadıklarında attacker tarafından yazılabilir olduğundan, özel hazırlanmış bir IhisiParamBuffer, rutin bir "sonucu buraya kaydet" operasyonunu bir arbitrary write primitive'ine dönüştürür. Attacker o write'ı gSecurity2'ye nişanlar ve image authentication'ı etkisiz hale getirir.

Aşılan boundary: imzalı (Microsoft third-party UEFI CA) bir uygulama, doğrulanmamış, dışarıdan kontrol edilen kalıcı veriyi trusted bir memory adresi olarak ele alıyor. Signature, binary'yi kimin derlediğini kanıtlar, input'larının güvenli olduğunu değil — yani imzalı binary exploitation aracı haline geliyor. Bu, secure-boot-bypass-via-custom-pe-loader ile aynı "imzalı bileşen bypass'ın kendisidir" pattern'i ve secure-boot-bypass altında takip ediliyor.

Walkthrough

CERT/CC VU#806555 (ve ilişkili Binarly araştırması, CVE-2025-3052) zinciri kavramsal olarak anlatıyor — yalnızca defansif anlama amaçlı:

  • Attacker, IhisiParamBuffer runtime NVRAM variable'ına özel hazırlanmış bir değer yazıyor (mümkün, çünkü kilitli değil / boot'ta yazılabilir kalıyor).
  • Vulnerable, Microsoft tarafından imzalı bir uygulama (DTBios / BiosFlashShell) ESP üzerinde yerleştiriliyor — bir Bring-Your-Own-Vulnerable-Binary yaklaşımı — ve geçerli şekilde imzalı olduğu için Secure Boot enabled bir makinede bile boot sırasında çalıştırılıyor.
  • App, attacker'ın kontrol ettiği pointer'ı dereference ediyor ve attacker'ın gSecurity2'ye (Security2 Architectural Protocol pointer'ı) yönlendirdiği bir write gerçekleştiriyor.
  • Authentication yolu çökertildikten sonra, sonraki imzasız UEFI kodu — bir bootkit — Secure Boot hâlâ enabled görünürken yüklenip çalışıyor.
Variable neden kaldıraç

Kusur variable'ın var olması değil; pointer-tipli bir değerin değiştirilebilir kalıcı depolamadan gelip bounds veya sanity kontrolü olmadan dereference edilmesi. Adres olarak da iş gören her "parameter buffer", depolama attacker tarafından yazılabilir olduğunda gizli bir arbitrary write'tır.

Detection

  • ESP / firmware avlama: boot uygulamaları olarak yerleştirilmiş beklenmeyen DtBios*.efi veya BiosFlashShell*.efi binary'leri normal bir sistemde anormaldir.
  • Known-bad hash'ler: CERT/Microsoft, etkilenen binary'lerin Authenticode hash'lerini yayınladı (CERT/Microsoft'un bildirdiğine göre dbx için 14 hash planlandı — kesin sayı advisory'ye göre değişebilir, load-bearing değildir); varlıklarında alert üretin.
  • NVRAM anomalileri: IhisiParamBuffer variable'ına (GUID 92E59835-5F42-4E0B-9A84-47C7810EA806) beklenmeyen write'lar, veya kilitli olması gerekirken runtime'da kalıcı/yazılabilir olması.
  • Measured boot: known-good baseline'a karşı PCR sapması (özellikle PCR 4/7), değiştirilmiş bir pre-OS zinciri veya Secure Boot policy durumu işareti.
  • Firmware integrity taraması: Binarly/Eclypsium tarzı tooling known-vulnerable modülü hash ile flag'liyor.
  • dbx doğrulaması: revocation hash'lerinin platform dbx'inde mevcut olduğunu teyit edin (Windows'ta Get-SecureBootUEFI dbx, Linux'ta dbxtool).

Mitigation

  • DBX revocation'ını uygulayın. Microsoft, etkilenen binary hash'lerini Forbidden Signature Database'e (DBX) ekledi. Güncellenmiş dbx'i OEM BIOS güncellemeleri, Windows Update veya LVFS (fwupd) üzerinden deploy edin ve uygulandığını teyit edin.
  • Vendor firmware/BIOS'unu düzeltilmiş bir build'e güncelleyin (ör. GIGABYTE ve diğer OEM'ler yamalı BIOS gönderdi); DTResearch etkilenen Microsoft tarafından imzalı binary'leri revoke etti.
  • Runtime NVRAM'ı kilitleyin mümkün olduğu yerde, böylece IhisiParamBuffer gibi variable'lar boot policy belirlendikten sonra değiştirilemesin.
  • Tasarım dersi: kalıcı/NVRAM kaynaklı veriyi asla trusted bir pointer olarak ele almayın; kullanmadan önce dışarıdan etkilenen tüm adresleri doğrulayın ve sınırlandırın.

References