Binarly SMM callout, Gigabyte AMD (BRLY-2022-044 / CVE-2023-20558)¶

Bir Gigabyte AMD UEFI SMM driver'ındaki bir SMI handler'ı, SMRAM dışında yaşayan bir function pointer'a callout yapar; bu da ring-0 kodunun SMM execution'ını yeniden yönlendirmesine ve ring 0'dan ring -2'ye yükselmesine olanak tanır.

Mechanism¶

Neden çalışır — SMM, OS'in overwrite edebileceği bir pointer'ı dereference eder

System Management Mode (SMM), x86'nın "ring -2"sidir: kodu ve verisi, OS'ten ve hatta hypervisor'dan kilitlenerek ayrılmış SMRAM'de durur. Bir SMI handler'ı orada tam physical-memory erişimiyle çalışır. Savunmacı invariant, SMM kodunun yalnızca SMRAM içindeki veriye ve koda bağımlı olması gerektiğidir, çünkü dışarıdaki her şey bir ring-0 attacker tarafından yazılabilir.

Bir SMM callout bu invariant'ı bozar. Handler, SMRAM içinde çalışırken, SMRAM dışındaki OS'e ait memory'de bulunan bir pointer (bir function pointer, bir UEFI protocol interface'i ya da DXE zamanında cache'lenen gBS/gRT boot/runtime-services pointer'ları) okur, ardından onun üzerinden call yapar. Pointer'ın storage'ı ring 0'dan erişilebilir olduğu için, attacker SMI'yi tetiklemeden önce onu kendi payload'unun adresiyle overwrite eder. Handler daha sonra kontrolü hâlâ SMM içindeyken attacker koduna devreder — ring -2'de arbitrary code execution.

Binarly'nin [BRLY-2022-044]'ü (AMD PSIRT tarafından CVE-2023-20558 atandı, CVSS 7.5, High) AMD tabanlı Gigabyte cihazlarında tam olarak bu class'tır: bir callout üzerinden hijack edilebilen bir SMM driver'ı, "potansiyel bir attacker'ın System Management Mode'da çalışan kodun execution flow'unu hijack etmesine olanak tanır." Getirisi ciddidir: SMM kodu, SMM tabanlı SPI-flash write protection'larını bypass edebilir ve OS reinstall'larından sağ çıkan kalıcı bir firmware implant kurabilir; BIOS region'ında yapılan bu değişiklikler Secure Boot'un güven zincirini firmware seviyesinde tehlikeye atabilir. Ancak farklı koruma mekanizmaları eşit değildir: unsigned bir BIOS implant'ı Boot Guard'ın başlangıç doğrulamasını doğrudan devre dışı bırakmaz (yalnızca imzasız olduğu için engellenir), ve SMM bir hypervisor'ın EPT tabanlı memory isolation'ını doğrudan bypass edemez.

Walkthrough¶

Aşağıdaki pattern, bir callout'un açıklayıcı biçimidir (kamuya açık SMM-callout research'ünden) — bu spesifik driver için weaponize edilmiş bir handler değil.

Vulnerable bir handler, non-SMRAM memory'deki bir pointer üzerinden call yapar:

// gBS was cached during DXE; its storage is OUTSIDE SMRAM (OS-writable)
extern EFI_BOOT_SERVICES *gBS;

EFI_STATUS EFIAPI SmiHandler (...) {
  // ...inside SMRAM, but gBS->LocateProtocol lives outside SMRAM...
  gBS->LocateProtocol (&SomeGuid, NULL, &Interface);  // CALLOUT
  ((SOME_PROTO *)Interface)->Method (Interface);       // calls attacker-controlled fn ptr
}

Kavramsal exploitation path'i (yalnızca ring-0 / local admin gerektirir):

1. Map the physical page holding the out-of-SMRAM pointer (gBS, or the protocol interface).
2. Overwrite the target function pointer with the address of a payload buffer in low RAM.
3. Trigger the SMI that reaches the vulnerable handler (e.g. write to APMC port 0xB2).
4. The handler, executing in SMRAM, calls through the poisoned pointer -> payload runs at ring -2.

Beklenen sonuç: kod, kısıtlanmamış physical erişimle SMM context'inde çalışır. Oradan bir attacker, BIOS_CNTL protection'larını temizleyip SPI'yi reflash edebilir; OS'in yenemeyeceği savunmaları yenerek.

Yalnızca savunma amaçlı kullanım

Bu kayıt, tespit ve remediation için zaten açıklanmış, vendor tarafından patch'lenmiş bir sorunu belgeler. Patch'lenmemiş production firmware'e karşı somut bir exploit inşa etmeyin.

Detection¶

CHIPSEC. SMM modüllerini çalıştırın: chipsec_main -m common.smm (SMRAM lock/D_LCK), -m common.smrr (SMRR) ve -m common.smm_dma (TSEG/SMRAM DMA protection). SMI pointer input'larını fuzz etmek ve fault veren handler'ları ortaya çıkarmak için tools.smm.smm_ptr kullanın.
Firmware diffing / statik analiz. SMM driver'larını disassemble edin (IDA + efiXplorer / Binarly'nin tooling'i) ve gBS, gRT ya da storage'ı SMRAM dışında olan bir protocol interface pointer'ı üzerinden call yapan herhangi bir handler'ı işaretleyin.
Version kontrolü. Kurulu BIOS versiyonunu, etkilenen modeller için Gigabyte'ın düzeltilmiş release'leriyle karşılaştırın; fix'in yokluğu en güçlü sinyaldir.

Mitigation¶

Tüm callable pointer'ları SMRAM içinde tutun

CVE-2023-20558 (ve kardeş BRLY-2022-045) için Gigabyte/AMD firmware update'ini uygulayın. ROM seviyesindeki bir bug için tek eksiksiz fix, vendor patch'idir.
SMM driver'ları callout yapmamalıdır: gereken services/interface'leri SMM-ready zamanında SMRAM içinde cache'leyin ve bir SMI handler'ından asla DXE-era bir gBS/gRT pointer'ını dereference etmeyin.
Başarılı bir callout'un kalıcı bir implant'a yükselememesi için platform lock'larının ayarlandığından emin olun: SMRAM D_LCK, SMRR, BIOS_CNTL BLE/SMM_BWP ve SPI flash protected range'ler (bkz. SPI flash BIOS write-protection misconfig).

Ayrıca bkz.: SMM callout, Binarly SMM callout class, SMRAM not locked.