Eksploit Fabricked ukrycie niszczy fizyczną ochronę chipów EPYC z pełną skutecznością – AMD już wydała poprawkę

Eksploit Fabricked ukrycie niszczy fizyczną ochronę chipów EPYC z pełną skutecznością – AMD już wydała poprawkę

28 hardware

Krótka treść

W kwietniu badacze z ETH Zurych odkryli lukę w sprzętowej ochronie AMD SEV‑SNP, która pozwala atakującemu na pełny dostęp do zaszyfrowanej pamięci maszyny wirtualnej (CVM) na procesorach AMD EPYC. Exploit o nazwie Fabricked wykorzystuje słabości routingu pamięci przez Infinity Fabric podczas uruchamiania i może oszukać kryptograficzną atestację, której użytkownicy polegają na sprawdzaniu integralności swojego środowiska.

1. Czym jest AMD SEV‑SNP i po co
* Obliczenia poufne pozwalają najemcom chmury upewnić się, że dostawca nie może czytać ich danych.
* SEV‑SNP tworzy sprzętowo izolowane maszyny wirtualne: pamięć jest szyfrowana, a dostęp kontrolowany przez wbudowany procesor bezpieczeństwa – PSP (Platform Security Processor).
* Podczas uruchamiania PSP inicjalizuje Reverse Map Table (RMP) – tabelę dostępu do każdej strony pamięci.
Atestacja (kryptograficzna weryfikacja) zależy od poprawnego działania RMP.

2. Jak działa Fabricked
1. Problem w UEFI
* Urządzenia AMD używają UEFI do konfiguracji Infinity Fabric – sieci międzychipowej, która routuje ruch pamięci pomiędzy rdzeniami, kontrolerami i peryferiami.
* W trakcie uruchamiania UEFI wywołuje dwa API PSP, które „blokują” rejestry konfiguracyjne Infinity Fabric po ich ustawieniu.
* Jeśli UEFI zostanie podmienione (co jest możliwe, ponieważ kontrolowane są przez dostawców chmury), te wywołania można pominąć, pozostawiając Data Fabric dostępny do zapisu nawet po aktywacji SEV‑SNP.
2. Brak weryfikacji MMIO
* Przy żądaniach PSP o dostęp do pamięci najpierw sprawdzane są zasady MMIO (do interakcji z urządzeniami sprzętowymi), a potem zwykłe zasady DRAM.
* Atakujący może skonfigurować mapowania MMIO tak, aby „cieniowały” obszar RMP. W rezultacie zapisy PSP są ignorowane, ale SEV‑SNP nadal zgłasza pomyślną inicjalizację.
3. Wynik – niezainicjowana RMP pozostaje pod kontrolą atakującego. Hypervisor zyskuje możliwość czytania i pisania w dowolne obszary pamięci CVM bez wykrycia przez system operacyjny gościa.

3. Demonstracja exploitów
* Włączenie trybu debugowania na działającej CVM po atestacji – hypervisor potrafi odszyfrować dowolną część pamięci, pozostając niezauważony.
* Masowe podmienianie raportów o atesacji – pozwala atakującemu udzielać fałszywych potwierdzeń integralności środowiska.

4. Co to oznacza dla użytkowników
* Luka jest w pełni deterministyczna i ma 100 % szans na sukces bez fizycznego dostępu do serwera.
* Nie wymaga wykonywania kodu wewnątrz maszyny wirtualnej – wystarczy host chmurowy, który kontroluje UEFI.
* Użytkownicy polegający na SEV‑SNP dla obliczeń poufnych ryzykują utratę kontroli nad swoimi danymi.

5. Co mówią badacze
Wyniki opublikowano w artykule *USENIX Security 2026*. Autorzy podkreślają, że Fabricked omija kluczowy mechanizm atesacji i demonstrują praktyczne exploity potwierdzające powagę zagrożenia.

Wniosek:

Fabricked ujawnia fundamentalną lukę w łańcuchu ochrony AMD SEV‑SNP. Jeśli nie zostaną podjęte środki aktualizacji UEFI i wzmocnienia weryfikacji RMP, dostawcy chmury mogą uzyskać pełny dostęp do zaszyfrowanej pamięci maszyn wirtualnych bez wykrycia przez najemców.

Komentarze (0)

Podziel się swoją opinią — prosimy o uprzejmość i trzymanie się tematu.

Nie ma jeszcze komentarzy. Zostaw komentarz i podziel się swoją opinią!

Aby dodać komentarz, zaloguj się.

Zaloguj się, aby komentować