Firma AMD włączyła procesory oparte na mikroarchitekturze Zen 5 do listy produktów narażonych na podatność EntrySign, która pozwala na obejście mechanizmu weryfikacji cyfrowego podpisu podczas aktualizacji mikrokodu. Początkowo przypuszczano, że podatność dotyczy tylko procesorów AMD opartych na 1-4 pokoleniach mikroarchitektury Zen. Tak więc podatność okazała się dotyczyć takich procesorów, jak Ryzen 9000 (Granite Ridge), EPYC 9005 (Turin), Ryzen AI 300 (Strix Halo, Strix Point, Krackan Point) oraz Ryzen 9000HX (Fire Range).
Oprócz aktualizacji mikrokodu, w celu usunięcia podatności w systemach wykorzystujących certyfikację SEV-SNP, wymagana jest również aktualizacja oprogramowania sprzętowego AMD SEV, które jest dostarczane w ramach aktualizacji BIOS. Podobno firma AMD przekazała producentom sprzętu zmienione oprogramowanie sprzętowe (ComboAM5PI 1.2.0.3c AGESA), które jest niezbędne do rozwiązania problemu, ale dostępne dla konsumentów finalne aktualizacje BIOS mogą zostać wydane przez producentów dopiero po tygodniach lub miesiącach.
Pracownicy AMD zaproponowali również włączenie do jądra Linux łatki, która blokuje ładowanie nieoficjalnych aktualizacji mikrokodu (zauważa się, że poprawne aktualizacje mikrokodu należy zainstalować razem z BIOS od producenta sprzętu, ale już pojawiły się próby stworzenia przez entuzjastów nieoficjalnych poprawek opartych na fragmentach mikrokodu wyciętych z BIOS). Użytkownikom zaleca się poczekać na oficjalne aktualizacje BIOS.
Możliwość zmiany mikrokodu, którą oferuje podatność EntrySign, pozwala na skompromitowanie mechanizmu AMD SEV (Secure Encrypted Virtualization), stosowanego w systemach wirtualizacji w celu ochrony maszyn wirtualnych przed ingerencją ze strony hypervisora lub administratora systemu hosta. W trakcie ataku można wniknąć w działanie systemów gościnnych, zabezpieczonych przy pomocy rozszerzeń AMD SEV (Secure Encrypted Virtualization) i SEV-SNP (Secure Nested Paging), które zapewniają gwarancje integralności pamięci maszyn wirtualnych, izolujące rejestry procesora i zapewniające bezpieczne operacje na zagnieżdżonych tabelach stron pamięci.
Vulnerability is caused by the use of the CMAC algorithm for verifying microcode instead of a reliable hash function. AMD uses a private RSA key to certify the microcode loaded into the processor with a digital signature, and the patch includes a public key. To verify that the public key corresponds to the original pair of RSA keys, the processor performs a hash match of the AMD public key, embedded during manufacturing into the CPU, with the hash from the public key specified in the patch.
The authenticity of the microcode in the patch is verified by comparing the hash supplied with the patch, certified by a digital signature (RSASSA-PKCS1-v1_5), and the hash computed based on the actual microcode supplied in the patch. If the reference and computed hashes match, the patch is loaded into the CPU's internal memory. The issue is that instead of using recommended cryptographically secure hash functions, the CMAC algorithm, which is not designed for such operations and is not collision-resistant, has been used.
CMAC is not a hash function; it implements a Message Authentication Code (MAC) that depends on an encryption key. The operation of AES-CMAC boils down to using the cryptographic algorithm AES and combining the result of its application with the next block of data using an XOR operation. This scheme guarantees that a change in the input data will lead to an unpredictable change in the output data. However, it is inappropriate to use CMAC as a hash function because anyone who knows the original encryption key can learn the intermediate encryption states and compute values that can compensate for changes in the input data, so that the result of applying CMAC remains unchanged.
AMD stosuje do AES-CMAC jeden klucz szyfrowania, dostarczany na wszystkich CPU, zaczynając od Zen 1. W ten sposób wystarczy wydobyć ten klucz z dowolnego CPU AMD, aby był on stosowany we wszystkich innych CPU. Badacze odkryli, że do szyfrowania AES-CMAC w AMD wykorzystano znany klucz, wzięty z przykładu wymienionego w wytycznych dotyczących stosowania szyfrów blokowych NIST SP 800-38B. Ponieważ AES-CMAC jest używany do haszowania wbudowanego w łatkę klucza RSA oraz zawartości mikrokodu, określając klucz szyfrowania AES-CMAC, staje się możliwe wstawienie w łatkę innego publicznego klucza RSA i zmiany zawartości mikrokodu.
Aby stworzyć fałszywą łatkę, wystarczy wygenerować nowy publiczny klucz, który wygeneruje ten sam hash, co autentyczny publiczny klucz AMD, oraz dopasować kolizje dla podpisu cyfrowego. Kolizje tworzy się, dołączając do mikrokodu dodatkowy blok, który wygląda jak zbiór losowych danych. W ten sposób można przygotować zmienioną łatkę z mikrokodem, odpowiadającą podpisowi cyfrowemu, którym została uwierzytelniona oryginalna łatka od AMD. Narzędzie Zentool, obejmujące programy do analizy mikrokodu i tworzenia łatek do zmiany mikrokodu, jest dostępne na licencji Apache 2.0. Aby wymienić mikrokod, wymagane są uprawnienia do uruchamiania kodu na poziomie zerowym (technologie VT-x i AMD-V pozwalają systemom gościnnym działać z uprawnieniami Ring 0).
Źródło: opennet.ru
