Wprowadzenie do problemu / definicja luki
W płytach głównych wielu wiodących producentów (ASRock, Asus, Gigabyte, MSI) wykryto podatność umożliwiającą ataki DMA na bardzo wczesnym etapie rozruchu (pre-boot). Choć firmware sygnalizuje aktywne zabezpieczenie DMA, w rzeczywistości IOMMU nie jest poprawnie inicjalizowane do momentu tuż przed przekazaniem kontroli systemowi operacyjnemu. W efekcie złośliwe urządzenie PCIe z dostępem fizycznym może czytać/pisać pamięć przed startem OS i jego mechanizmów ochronnych.
W skrócie
- Dotyczy: wybranych modeli płyt głównych ASRock, Asus, Gigabyte, MSI. Inni dostawcy firmware (AMI, Insyde, Phoenix), producenci CPU (Intel, AMD) i Supermicro zgłaszają „nie dotyczy” w ramach tego problemu.
- Identyfikatory: m.in. CVE-2025-11901, CVE-2025-14302, CVE-2025-14303, CVE-2025-14304 (różne warianty u poszczególnych vendorów).
- Wektor ataku: fizyczny dostęp i wpięcie złośliwego urządzenia PCIe (np. karta z DMA).
- Skutki: odczyt/zapis pamięci w fazie pre-boot, możliwość pozyskania tajnych danych i wstrzyknięcia kodu przed rozruchem.
- Odkrycie i koordynacja: badacze Riot Games; koordynacja przez CERT/CC (Carnegie Mellon).
- Status poprawek: producenci publikują aktualizacje BIOS/UEFI; w przypadku Gigabyte dostępne dla wielu rodzin (Intel 600/700/800; AMD 600/800; TRX50 zapowiedziane na Q1 2026).
Kontekst / historia / powiązania
CERT/CC opublikował notę VU#382314 17 grudnia 2025 r., dokumentując problem i status dostawców. Wpisy producentów płyt oraz wpisy NVD/CVE uszczegóławiają, które serie są objęte (np. Asus: Z490–Z790 i W790) oraz jakie CVE przypisano poszczególnym wariantom (np. MSI: CVE-2025-14303). Wykrycie przez zespół Riot ma także konsekwencje dla antycheatów – dziura podważała zaufanie do „Pre-Boot DMA Protection”, a Riot zapowiedział egzekwowanie aktualizacji firmware u graczy.
Analiza techniczna / szczegóły luki
Mechanizm Pre-Boot DMA Protection polega na użyciu IOMMU do izolacji urządzeń DMA już podczas rozruchu. W dotkniętych implementacjach UEFI występuje rozjazd między raportem a stanem faktycznym: firmware twierdzi, iż ochrona DMA jest aktywna, ale IOMMU nie jest w pełni skonfigurowane aż do bardzo późnego etapu rozruchu. Ta „luka czasowa” pozwala urządzeniu PCIe na dostęp do pamięci fizycznej (R/W) przed inicjalizacją zabezpieczeń OS, co klasyfikowane jest jako CWE-693: Protection Mechanism Failure.
W przypadku MSI błąd ujęto właśnie jako Protection Mechanism Failure (CVE-2025-14303) – niepoprawne włączenie IOMMU umożliwia nieautoryzowany DMA w fazie pre-boot.
Praktyczne konsekwencje / ryzyko
- Wymóg fizycznego dostępu ogranicza skalę ataków, ale ryzyko jest realne w środowiskach o podwyższonym zagrożeniu (colo, laboratoria, stanowiska serwisowe, stanowiska VIP), gdzie złośliwe peryferia mogą zostać dyskretnie podłączone.
- Pre-boot code injection podważa integralność łańcucha rozruchu i może umożliwić trwałe ominięcie kontroli bezpieczeństwa na poziomie OS/hypervisora, a w środowiskach wirtualnych wpływać na izolację i delegację zaufania.
- Ekosystem gier/anticheat: luka otwierała drogę do sprzętowych cheatów działających poza zasięgiem typowych detektorów; wydawcy mogą wymagać aktualizacji BIOS/UEFI.
Rekomendacje operacyjne / co zrobić teraz
- Aktualizuj BIOS/UEFI do wersji oznaczonych jako naprawiające problem (sprawdź tabelę/biuletyn producenta swojej płyty).
- Gigabyte: poprawki opublikowane dla licznych rodzin (Intel 600/700/800; AMD 600/800), TRX50 – Q1 2026.
- MSI: śledź doradztwa bezpieczeństwa i wpis CVE-2025-14303.
- Asus: zaktualizuj BIOS dla serii Z490–Z790/W790 i w BIOS ustaw IOMMU DMA Protection na „Enable with Full Protection”.
- Zweryfikuj ustawienia IOMMU/VT-d po aktualizacji (nie „Auto”). jeżeli producent przewiduje tryb „Full Protection” / „Enable during boot”, włącz go manualnie.
- Zarządzaj dostępem fizycznym: ogranicz możliwość podpinania urządzeń PCIe/Thunderbolt, stosuj plombowanie obudów, kontroluj porty w strefach o podwyższonym ryzyku.
- Higiena łańcucha rozruchu: weryfikuj Secure Boot, rejestry zdarzeń rozruchu, integrację z EDR/HVCI; po krytycznych aktualizacjach przeprowadź rekonsyliację stanów bezpieczeństwa. (Zalecenie ogólne na bazie dobrych praktyk.)
- Środowiska VDI/hiperwizora: po poprawkach wykonaj testy izolacji urządzeń passthrough i vIOMMU, bo błąd dotyczył właśnie wczesnej fazy inicjalizacji.
Różnice / porównania z innymi przypadkami
W przeciwieństwie do wcześniejszych problemów Secure Boot/UEFI (np. klasyczne obejścia Secure Boot czy „Hydroph0bia”), obecna podatność nie polega na złamaniu podpisów czy list zaufania, ale na oknie czasowym w inicjalizacji IOMMU – czyli ochrony przed DMA. To ataki sprzętowe z fizycznym wektorem, które uderzają w fundament izolacji pamięci zanim OS wystartuje.
Podsumowanie / najważniejsze wnioski
- Błąd w implementacjach UEFI sprawia, iż IOMMU nie chroni pamięci wystarczająco wcześnie, co otwiera drogę do pre-boot DMA.
- Ryzyko dotyczy wybranych płyt Asrock/Asus/Gigabyte/MSI; inni kluczowi dostawcy zgłosili brak wpływu.
- Aktualizacje BIOS/UEFI już są dostępne (publikowane sukcesywnie) – po aktualizacji wymuś tryb pełnej ochrony IOMMU.
- W środowiskach o niższym zaufaniu fizycznym priorytetem jest patching i polityki kontroli dostępu do portów/slotów.
Źródła / bibliografia
- SecurityWeek: „UEFI Vulnerability in Major Motherboards Enables Early-Boot Attacks” (18 grudnia 2025). (SecurityWeek)
- CERT/CC VU#382314: „Vulnerability in UEFI firmware modules prevents IOMMU initialization…” (17 grudnia 2025). (kb.cert.org)
- Riot Games (Vanguard): „Security Update: Closing the Pre-Boot Gap” (grudzień 2025). (Riot Games)
- Gigabyte – Security Advisory „Vulnerability in UEFI Firmware Modules Prevents IOMMU Initialization…” (17 grudnia 2025). (GIGABYTE)
- NVD – CVE-2025-14303 (MSI) – opis i metryki. (nvd.nist.gov)
