Ataki Mior i Skyfall osłabiają ochronę poufnych maszyn wirtualnych AMD SEV-SNP

securitybeztabu.pl 1 dzień temu

Wprowadzenie do problemu / definicja

Poufne przetwarzanie w chmurze ma zapewniać, iż dane uruchamiane wewnątrz chronionej maszyny wirtualnej pozostają niedostępne choćby 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, iż 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, iż 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, iż 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, choćby jeżeli 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 iż ś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, choćby 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, iż 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. o ile 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. choćby 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 kooperacja 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ą, iż 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 najważniejsze 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.