
Wprowadzenie do problemu / definicja
Poufne przetwarzanie w chmurze ma zapewniać, że dane uruchamiane wewnątrz chronionej maszyny wirtualnej pozostają niedostępne nawet dla operatora hosta czy hiperwizora. W ekosystemie AMD taką funkcję pełni mechanizm SEV-SNP, który łączy szyfrowanie pamięci, kontrolę własności stron oraz atestację środowiska uruchomieniowego.
Ujawnione techniki Mior i Skyfall pokazują jednak, że w określonych scenariuszach złośliwy host może osłabić te gwarancje. To istotny sygnał ostrzegawczy dla organizacji korzystających z confidential VMs w chmurze i środowiskach on-premises.
W skrócie
- Mior umożliwia odczyt i modyfikację pamięci chronionej maszyny wirtualnej.
- Atak może także podważyć wiarygodność atestacji uruchamianego obrazu.
- Skyfall wykorzystuje wycieki mikroarchitekturalne do odzyskiwania fragmentów stanu procesora.
- W określonych warunkach możliwe jest przejęcie danych wrażliwych, w tym materiału kryptograficznego.
- Usunięcie ryzyka wymaga aktualizacji firmware, mikrokodu i komponentów platformowych.
Kontekst / historia
SEV-SNP powstał jako rozwinięcie wcześniejszych technologii SEV i SEV-ES, aby lepiej chronić maszyny wirtualne przed wrogim lub przejętym hiperwizorem. Jednym z kluczowych elementów tego modelu jest Reverse Map Table, która śledzi właściciela strony pamięci i określa dozwolone operacje.
Drugim filarem bezpieczeństwa jest atestacja, pozwalająca klientowi sprawdzić, czy uruchomiona instancja rzeczywiście odpowiada oczekiwanej konfiguracji. Nowe badania wpisują się w rosnący trend pokazujący, że skuteczność confidential computing zależy nie tylko od szyfrowania pamięci, ale także od integralności startu platformy, jakości firmware i zachowania samej mikroarchitektury procesora.
Analiza techniczna
Atak Mior koncentruje się na fazie inicjalizacji SEV-SNP. W opisywanym scenariuszu komponent bezpieczeństwa procesora uzupełnia strukturę Reverse Map Table podczas rozruchu. Badacze wykazali, że przy kontroli nad hiperwizorem, BIOS/UEFI oraz odpowiednio wykorzystanym urządzeniem PCIe możliwe jest przekierowanie operacji zapisu wykonywanych w tym etapie.
Skutkiem jest częściowo błędna inicjalizacja tabeli RMP, co z kolei pozwala zmienić ochronę przypisaną stronom pamięci. W praktyce otwiera to drogę do aktywacji debugowania dla poufnej maszyny wirtualnej, nawet jeśli opcja ta była wyłączona. Następnie atakujący może użyć funkcji debugowania do odczytu i zapisu pamięci VM.
Szczególnie groźny jest wariant, w którym pomiar legalnego obrazu zostaje skopiowany do obrazu złośliwego. W takiej sytuacji raport atestacyjny może sugerować uruchomienie zaufanej konfiguracji, mimo że środowisko zostało wcześniej zmodyfikowane.
Skyfall reprezentuje inną klasę zagrożeń. Atak bazuje na ubocznych efektach działania mikroarchitektury i wykorzystuje moment nieudanego startu maszyny wirtualnej. Część stanu VM zostaje załadowana do struktur procesora, ale nie jest w pełni wyczyszczona po przerwaniu uruchamiania.
Złośliwy hiperwizor może następnie odzyskiwać pozostałości tego stanu przy użyciu kanału bocznego opartego na czasie wykonania. W badaniach wykazano możliwość odzyskiwania wartości rejestrów, wybranych danych z cache, a w niektórych scenariuszach także kluczy kryptograficznych, takich jak klucz szyfrowania dysku testowej maszyny wirtualnej.
Choć Skyfall nie daje pełnego i swobodnego odczytu całej pamięci gościa, nawet częściowy wyciek może mieć bardzo wysoką wartość operacyjną. Dotyczy to zwłaszcza tokenów sesyjnych, kluczy krótkotrwałych i innych sekretów chwilowo przechowywanych w rejestrach.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko dotyczy środowisk wielodzierżawnych, w których confidential computing ma chronić dane przed administratorem hosta. Mior pokazuje, że przy kompromitacji warstwy firmware oraz kontroli nad platformą możliwe jest jednoczesne naruszenie poufności, integralności i zaufania do atestacji.
To szczególnie niebezpieczne dla organizacji przechowujących w takich instancjach klucze prywatne, dane finansowe, informacje medyczne lub wrażliwe modele AI. Jeżeli raport atestacyjny przestaje wiarygodnie odzwierciedlać stan uruchomionego środowiska, cały model zaufania zostaje osłabiony.
Skyfall ma inny profil ryzyka, ale pozostaje realnym zagrożeniem tam, gdzie atakujący kontroluje host lub działa z wysokimi uprawnieniami. Nawet ograniczony wyciek rejestrów może wystarczyć do przejęcia sekretów potrzebnych do dalszej eskalacji dostępu.
Ważnym problemem jest również zależność od dostawcy infrastruktury. Ponieważ poprawki dotyczą firmware i mikrokodu, najemca chmury nie usunie podatności samodzielnie z poziomu systemu gościa. Konieczna jest współpraca operatora chmury, producenta serwera i dostawcy aktualizacji BIOS/UEFI.
Rekomendacje
Organizacje korzystające z AMD SEV-SNP powinny w pierwszej kolejności ustalić, czy ich środowiska bazują na podatnych platformach EPYC oraz czy wdrożono już wymagane aktualizacje mikrokodu, SEV firmware i BIOS/UEFI. Sama obecność wsparcia dla confidential computing nie jest wystarczająca bez potwierdzenia aktualnego stanu TCB.
W środowiskach lokalnych warto wdrożyć regularną walidację firmware hostów, obejmującą BIOS, BMC oraz inne pakiety platformowe. Należy także ograniczyć możliwość modyfikacji ustawień rozruchowych i egzekwować bezpieczny łańcuch startu komponentów platformy.
- prowadzić audyt zmian w BIOS, UEFI i konfiguracji PCIe,
- ograniczać dostęp administracyjny do hiperwizorów,
- segmentować obowiązki zespołów operacyjnych,
- regularnie weryfikować pomiary atestacyjne i wartości TCB,
- monitorować zgodność platform z zaleceniami producenta.
Dla obciążeń o najwyższej krytyczności warto stosować podejście defense in depth. Obejmuje ono dodatkowe szyfrowanie danych aplikacyjnych, sealing kluczy do określonych stanów platformy, skracanie czasu przebywania sekretów w pamięci oraz częstą rotację materiału kryptograficznego.
Podsumowanie
Mior i Skyfall pokazują, że confidential computing nie eliminuje ryzyka związanego z warstwą sprzętową i firmware. W pierwszym przypadku zagrożona jest poufność pamięci, integralność maszyny wirtualnej oraz wiarygodność atestacji. W drugim problem dotyczy wycieków przez kanały boczne i pozostałości stanu mikroarchitekturalnego.
Dla organizacji korzystających z AMD SEV-SNP kluczowe znaczenie ma dziś szybka weryfikacja poziomu załatania hostów oraz traktowanie stanu firmware jako jednego z najważniejszych elementów bezpieczeństwa danych w chmurze.
Źródła
- The Hacker News — https://thehackernews.com/2026/11/new-mior-and-skyfall-attacks-let-rogue.html
- AMD Security Bulletin — https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7027.html
- AMD Security Bulletin — https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html