Luka Skitter w AMD ujawnia głęboką kontrolę sprzęttu wykraczającą poza szum wokół wyszukiwania amazon amd

AMD mierzy się obecnie z istotnym twierdzeniem dotyczącym bezpieczeństwa procesorów wprowadzonych mniej więcej w latach 2011–2015. Jedna instrukcja ma rzekomo ujawniać pamięć, do której sprzęt zwykle blokuje dostęp.

Exploit o nazwie Skitter Creek Bath Salts, czyli Skitter, jest wymierzony w procesory AMD Family 15h i 16h. Technikę opracował badacz bezpieczeństwa Christopher Domas, jak wynika z pierwszych doniesień o Skitter.

Wyrażenie amazon amd pojawia się w ścieżce odkrycia tej historii, lecz jej centrum nie stanowi żaden ujawniony incydent związany z Amazonem. Dotknięty problemem sprzęt należy do AMD, a dostępne relacje nie potwierdzają związku z Amazonem.

To rozróżnienie ma znaczenie, ponieważ leżący u podstaw problem bezpieczeństwa jest wystarczająco poważny bez wykraczania poza dostępne dowody. Skitter ma rzekomo zmieniać kontrolę mapowania, która chroni kilka silnie uprzywilejowanych regionów pamięci.

Regiony te obejmują pamięć związaną z Platform Security Processor, czyli PSP, który realizuje funkcje bezpieczeństwa poza głównym systemem operacyjnym. Obejmują też System Management Mode, pamięć poprawek mikrokodu oraz inne obszary specyficzne dla implementacji.

Uzyskanie dostępu do tych komponentów umieściłoby atakującego poniżej zwykłych aplikacji, systemu operacyjnego i wielu narzędzi ochronnych. Jednak dostęp do technicznej możliwości nie oznacza automatycznie praktycznego zdalnego ataku.

Główny konflikt nie dotyczy zatem AMD kontra inny producent układów. Chodzi o obiecywaną przez procesor sprzętową izolację oraz mechanizm, który ma rzekomo wyłączać tę izolację za pomocą jednej instrukcji.

Starsze systemy tworzą punkt największej presji. Często pozostają w sprzęcie przemysłowym, produktach wbudowanych, laboratoriach, biurach i komputerach entuzjastów długo po zakończeniu typowych cykli modernizacji konsumenckiej.

Skitter nie oznacza, że każdy taki komputer został już przejęty. Oznacza, że właściciele muszą ustalić, czy stary procesor nadal chroni granice zakładane przez ich model bezpieczeństwa.

Co Skitter ma zmieniać wewnątrz procesorów AMD

Skitter ma rzekomo przekształcać pojedynczy bit kontrolny w bramę do regionów pamięci, których zwykłe oprogramowanie nie może mapować.

Współczesne procesory wykonują więcej niż instrukcje aplikacji. Rozdzielają również pamięć między systemy operacyjne, firmware, urządzenia, hipernadzorców i wewnętrzne procesory bezpieczeństwa.

Ten podział określa, który komponent może odczytywać lub modyfikować każdy adres. Uniemożliwia zwykłemu oprogramowaniu traktowanie chronionej pamięci firmware jak normalnego bufora aplikacji.

Według pierwszego raportu procesory Family 15h i 16h zawierają bit wyłączający to ograniczenie mapowania. Domas miał odkryć, że jedna instrukcja może zmienić ten bit.

Bezpośrednim skutkiem nie jest po prostu kolejny wzrost uprawnień oprogramowania. Zmiana ma rzekomo ujawniać obszary, które pozostają niedostępne nawet dla konwencjonalnego kodu na poziomie jądra.

Jednym z celów jest Platform Security Processor. PSP to dedykowany podsystem bezpieczeństwa, który realizuje zaufane operacje niezależnie od głównych rdzeni procesora x86.

Funkcje firmware Trusted Platform Module mogą zależeć od tego podsystemu. fTPM przechowuje lub przetwarza pomiary i materiał kryptograficzny używany w funkcjach takich jak poświadczanie platformy.

Exploit ma również ujawniać System Management Mode. SMM to tryb pracy procesora wykorzystywany przez firmware do funkcji niskiego poziomu, takich jak zarządzanie zasilaniem i sprzętem.

Gdy działa SMM, normalny system operacyjny zostaje wstrzymany. Jego kod zajmuje chroniony region powszechnie nazywany SMRAM, do którego zwykłe oprogramowanie nie powinno mieć dostępu.

Microsoft opisuje SMM jako od dawna atrakcyjny cel ataków, ponieważ tradycyjnie zapewnia on szeroką kontrolę nad pamięcią i urządzeniami. Prace firmy nad izolacją SMM pokazują, dlaczego dostawcy traktują tę warstwę jako bardziej uprzywilejowaną niż system operacyjny.

Pamięć RAM poprawek mikrokodu to kolejny zgłaszany cel. Mikrokod tłumaczy lub kontroluje części implementacji przez procesor instrukcji architektury.

Dostawcy wykorzystują aktualizacje mikrokodu do korygowania zachowania procesora bez fizycznej wymiany układu. Nieautoryzowany dostęp mógłby zatem zagrozić założeniom przyjmowanym na poziomie instrukcji.

Obecne doniesienia opisują także dostęp do innych chronionych obszarów implementacji. Ich dokładne znaczenie będzie zależeć od modelu procesora, firmware, konstrukcji płyty głównej i ścieżki ataku.

Ta szerokość wyjaśnia określenie „pełna kontrola na poziomie sprzętowym”. Nadal jednak powinno ono opisywać potencjalny poziom uprawnień, a nie automatycznie niezawodne przejęcie każdej dotkniętej problemem maszyny.

Kompletny exploit musi zrobić coś użytecznego po otwarciu mapowania. Musi zidentyfikować region docelowy, obsłużyć różnice między modelami i zmodyfikować stan bez zawieszenia systemu.

Te kroki inżynieryjne odróżniają prymityw architektoniczny od niezawodnego złośliwego oprogramowania. Zgłaszana prostota Skitter dotyczy działania otwierającego granicę, a niekoniecznie całego łańcucha ataku.

Twierdzenie pozostaje wyjątkowo istotne, ponieważ izolacja pamięci ma być fundamentem. Zabezpieczenia programowe ponad tą granicą nie mogą w pełni zrekompensować sytuacji, w której sprzęt ujawnia chroniony stan.

Dotknięte rodziny obejmują więcej niż jedną znaną linię desktopową

Ryzyko wynika z identyfikatorów rodzin procesorów, a nie z logo AMD ani szerokiego wyrażenia wyszukiwania takiego jak amazon amd.

Family 15h obejmuje kilka architektur sprzed ery Zen AMD. Najbardziej znane przykłady to desktopowe procesory FX wywodzące się z Bulldozera oraz powiązane konstrukcje serwerowe lub procesory przyspieszone.

Archiwalny przewodnik Family 15h AMD dokumentuje sposób, w jaki firmware i jądra systemów identyfikują oraz konfigurują wczesnych przedstawicieli tej rodziny. Pokazuje też, dlaczego etykieta rodziny obejmuje więcej niż jedną nazwę handlową.

Family 16h obejmuje energooszczędne jednostki przyspieszonego przetwarzania i systemy wbudowane. Dokumentacja AMD wskazuje warianty desktopowe, notebookowe, tabletowe i wbudowane w tej rodzinie.

Archiwalny przewodnik Family 16h firmy został poprawiony w lutym 2015 roku. Ten termin pasuje do zgłaszanego końca okresu objętej problemem generacji.

Właściciele nie powinni identyfikować zagrożenia wyłącznie na podstawie oferty handlowej. Nazwy detaliczne, ponownie wykorzystywane etykiety produktów i niepełne opisy sprzedawców mogą ukrywać rzeczywistą rodzinę i model.

Dane CPUID procesora stanowią solidniejszy punkt wyjścia. Narzędzia systemu operacyjnego mogą wyświetlać rodzinę, model i stepping bez wykonywania eksperymentalnego kodu bezpieczeństwa.

Nazwa modelu nadal pomaga w pracach inwentaryzacyjnych. Należy ją sprawdzać względem identyfikatora rodziny, zamiast traktować jako rozstrzygający dowód.

To rozróżnienie staje się szczególnie ważne poza desktopami konsumenckimi. Płyty wbudowane mogą pozostawać wdrożone przez lata, ponieważ ich wymiana wymaga walidacji, dostępu fizycznego lub prac certyfikacyjnych.

Terminal punktu sprzedaży, kontroler laboratoryjny lub komputer fabryczny mogą niezawodnie wykonywać wąskie zadanie. Jego właściciel może nie widzieć istotnego powodu operacyjnego, by go wymieniać.

Bezpieczeństwo zmienia tę kalkulację. Maszyna nie staje się mało ryzykowna wyłącznie dlatego, że jej obciążenie jest przewidywalne lub interfejs użytkownika ograniczony.

Dokumentacja Family 16h obejmuje systemy wbudowane G-Series wraz z konfiguracjami konsumenckimi. Arkusz danych systemów wbudowanych AMD wymienia opcje dwu- i czterordzeniowe z kompatybilnością 32-bitową i 64-bitową.

Ten szeroki zakres tworzy wyzwanie inwentaryzacyjne. Organizacje mogą wiedzieć, że posiadają systemy AMD, ale nie mieć zapisów na poziomie modeli potrzebnych do szybkiej oceny narażenia.

Okres objęty problemem poprzedza również obecne praktyki zakupowe sprzętu w wielu firmach. Bazy zasobów mogą wymieniać urządzenie, lecz nie jego rodzinę procesora ani status firmware.

Kupujący używany sprzęt napotykają kolejny problem. Starsze desktopy FX i kompaktowe systemy nadal krążą na rynku, ponieważ mogą obsługiwać podstawowe zadania komputerowe, retrogranie, testy i specjalistyczne oprogramowanie.

Oferta znaleziona przez zapytanie amazon amd nie potwierdza, czy procesor jest dotknięty problemem, załatany, odizolowany lub wcześniej zmodyfikowany. Kupujący potrzebują dokładnego modelu i szczegółów dotyczących płyty.

Muszą także uwzględnić firmware płyty głównej. Bezpieczeństwo procesora rzadko działa niezależnie od konfiguracji BIOS-u, procedur obsługi firmware i specyficznych dla dostawcy decyzji wdrożeniowych.

Praktyczną jednostką oceny jest zatem cała platforma. Obejmuje ona procesor, płytę, wersję firmware, system operacyjny, sterowniki oraz fizyczne wdrożenie.

Mechanizm jednej instrukcji podważa izolację sprzętową

Skitter ma znaczenie, ponieważ zgłaszany mechanizm omija granicę, a nie jedynie wykorzystuje kod działający ponad nią.

Większość luk programowych zaczyna się od błędu w aplikacji, sterowniku, komponencie systemu operacyjnego lub procedurze obsługi firmware. Atakujący manipulują takim błędem, aby uzyskać wyższy poziom uprawnień.

Skitter ma rzekomo działać inaczej. Jego kluczowa operacja zmienia sposób, w jaki chronione adresy fizyczne są ujawniane głównemu procesorowi.

To sprawia, że sama mapa pamięci staje się centralnym mechanizmem bezpieczeństwa. Mapa określa, czy dany adres prowadzi do zwykłej pamięci, urządzenia czy wewnętrznego chronionego komponentu.

Kontrola wyłączająca ograniczenie może jednocześnie zniszczyć kilka odrębnych granic zaufania. System operacyjny nie może bezpiecznie pośredniczyć w dostępie do regionu, który procesor niespodziewanie czyni widocznym.

To zasadnicze odwrócenie sytuacji. Izolacja wspierana sprzętowo zwykle stanowi ostatnią linię obrony, gdy zwykłe uprawnienia programowe zostały już utracone.

Skitter ma rzekomo zamieniać tę ostatnią linię obrony w powierzchnię ataku. Ten sam mechanizm, który ma organizować dostęp, staje się ścieżką omijającą kontrole dostępu.

Christopher Domas od lat bada zachowanie procesorów poniżej zwykłych granic programowych. Jego wcześniejsze prace obejmują fuzzer procesorów Sandsifter oraz technikę eskalacji uprawnień Memory Sinkhole.

Biografia konferencyjna dotycząca jego badań procesorów wymienia także God Mode Unlocked, które analizowało sprzętowe backdoory w procesorach x86. To zapewnia kontekst, choć nie weryfikuje niezależnie każdego twierdzenia o Skitter.

Nową technikę należy też odróżniać od wcześniejszej pracy Domasa nad Memory Sinkhole. Memory Sinkhole manipulowało zachowaniem kontrolera przerwań mapowanego w pamięci, aby ingerować w chronioną pamięć SMM.

Skitter jest opisywany jako specyficzne dla AMD obejście mapowania dotyczące Family 15h i 16h. Zgłaszane ujawnienie PSP i mikrokodu daje mu szerszy zestaw celów.

Obie koncepcje podważają założenie, że chroniona pamięć firmware jest niedostępna po rozruchu. Nie należy jednak utożsamiać ich mechanizmów ani procesorów, których dotyczą.

Pojedyncza instrukcja nie oznacza też, że nieuprzywilejowana witryna internetowa może natychmiast przejąć komputer. Instrukcje kontrolne procesora często wymagają uprzywilejowanego kontekstu wykonania.

Dostępny publiczny raport wymaga jaśniejszych odpowiedzi dotyczących tego warunku wstępnego. Czytelnicy powinni szukać jednoznacznej demonstracji pokazującej poziom uprawnień wymagany, zanim bit mapowania będzie mógł zostać zmieniony.

Jeśli wymagane są uprawnienia jądra, atakujący musieliby najpierw wykorzystać inną lukę, złośliwy sterownik lub autoryzowany dostęp administracyjny. Skitter pogłębiałby wówczas istniejące naruszenie.

Ten scenariusz nadal jest poważny. Dostęp do jądra może zapewniać dużą kontrolę, lecz obrońcy nadal polegają na izolacji PSP, SMM i firmware'u, aby chronić sekrety oraz granice trwałości.

Atakujący, który dotrze do tych warstw, może potencjalnie przetrwać ponowną instalację systemu operacyjnego. Może też ukryć się przed narzędziami endpointowymi, które obserwują wyłącznie zwykłą pamięć i procesy.

Sama widoczność pamięci nie gwarantuje jednak trwałości. Atakujący musi znaleźć ścieżkę trwałej modyfikacji i uwzględnić specyficzne dla platformy zachowanie firmware'u.

Niezawodność ma znaczenie, ponieważ uszkodzenie mikrokodu lub stanu firmware'u może zatrzymać procesor. Zawieszający się proof of concept ma inną wartość operacyjną niż stabilny implant.

Dlatego niezależne materiały techniczne są niezbędne. Badacze potrzebują informacji o instrukcji, definicji rejestru, dotkniętych rewizjach, warunkach wstępnych oraz powtarzalnych wynikach na wielu płytach głównych.

Dopóki te szczegóły nie są publiczne, najsilniejszy wniosek pozostaje ograniczony. Zgłoszony prymityw podważa izolację sprzętową w określonych generacjach, lecz jego praktyczna wykorzystywalność pozostaje nie w pełni udokumentowana.

PSP, SMM i mikrokod tworzą trzy różne stawki bezpieczeństwa

Ujawnione regiony należą do różnych domen zaufania, dlatego każdy z nich tworzy odrębne ryzyko, a nie jeden ogólny scenariusz przejęcia kontroli.

PSP ma znaczenie, ponieważ działa poza głównym systemem operacyjnym x86. Usługi bezpieczeństwa mogą na nim polegać, nawet gdy zwykłe oprogramowanie ma uprawnienia administratora.

Jednym z przykładów jest fTPM. Obsługuje on pomiary i klucze wykorzystywane przez funkcje bezpieczeństwa systemu operacyjnego, ale implementacje i obsługa kluczy różnią się między platformami.

Dostęp do pamięci związanej z PSP nie ujawnia automatycznie każdego chronionego klucza. Daje jednak powód, by pytać, jakie dane stają się obserwowalne lub modyfikowalne.

Śledczy muszą ustalić, czy Skitter ujawnia działającą pamięć PSP, współdzielone bufory komunikacyjne, obrazy firmware'u czy wszystkie te elementy. Każdy wynik wiąże się z innym zagrożeniem.

SMM stanowi odrębny problem. Firmware wykorzystuje go do zarządzania sprzętem, ukrywając jego wykonywanie i pamięć przed systemem operacyjnym.

Kod wykonywany w tym środowisku może kontrolować pamięć lub urządzenia, nie pojawiając się jako zwykły proces. Ta nieprzejrzystość czyni SMM atrakcyjnym dla trwałych implantów.

Wytyczne bezpieczeństwa Microsoft wyjaśniają, w jaki sposób nowsze zabezpieczenia ograniczają SMM za pomocą uwierzytelnionego kodu i ograniczonych stron. Te późniejsze mechanizmy pokazują również, czego brakuje starszym platformom.

Jeśli Skitter pozwala zwykłemu kodowi x86 odczytywać lub zmieniać SMRAM, osłabiałby podstawowe założenia dotyczące poufności i integralności wokół SMM. Błędy firmware'u przestałyby być jedyną drogą do środka.

Pamięć RAM poprawek mikrokodu rodzi jeszcze głębsze pytanie. Mikrokod uczestniczy w tym, jak procesor wykonuje instrukcje i obsługuje wyjątkowe warunki.

Udana modyfikacja mogłaby potencjalnie zmienić zachowanie poniżej poziomu systemu operacyjnego. Tworzenie użytecznego mikrokodu jest jednak trudne, specyficzne dla modelu i słabo udokumentowane.

Rozróżnienie między odczytem a zapisem jest kluczowe dla wszystkich trzech celów. Dostęp do odczytu może ujawniać sekrety, a dostęp do zapisu może umożliwiać kontrolę lub trwałość.

Początkowy raport opisuje szeroki dostęp na poziomie sprzętowym, ale pełna ocena wymaga odrębnych demonstracji dla każdego regionu. Jedno udane mapowanie nie dowodzi identycznej kontroli wszędzie.

Obrońcy powinni również zapytać, czy stan przetrwa ponowne uruchomienie. Ulotna pamięć RAM poprawek może zostać wyzerowana, podczas gdy naruszona pamięć firmware'u mogłaby przywrócić modyfikację podczas rozruchu.

Odpowiedź determinuje strategię reagowania na incydenty. Ulotny eksperyment laboratoryjny może zniknąć po utracie zasilania, ale implant firmware'u wymaga silniejszego procesu odzyskiwania.

W tym miejscu sensacyjne sformułowania mogą zaciemniać użyteczną analizę. „Pełna kontrola” brzmi jak pojedynczy stan, choć platformy sprzętowe zawierają kilka niezależnych domen wykonawczych i pamięci masowej.

Staranny raport powinien określać, który komponent został odczytany, który zmodyfikowano oraz jak zweryfikowano wynik. Powinien też wyjaśniać, czy secure boot wpłynął na test.

Żadne dowody w dostępnych relacjach nie łączą tej podatności z infrastrukturą Amazon. Słowo kluczowe amazon amd jest zatem artefaktem wyszukiwania, a nie potwierdzonym stwierdzeniem o ofierze.

Ma to znaczenie dla klientów chmurowych. Ryzyko w chmurze publicznej zależy od faktycznie wdrożonych procesorów, mechanizmów kontroli hypervisora, wieku sprzętu i dostępu dostępnego wewnątrz maszyny gościnnej.

Maszyna wirtualna gościa zwykle nie może wydawać dowolnych uprzywilejowanych instrukcji hosta. Nawet gdyby mogła zakodować taką instrukcję, hypervisor powinien przechwycić lub odrzucić niebezpieczne operacje.

Twierdzenie o wykorzystaniu luki w chmurze wymagałoby dowodu, że gość może dotrzeć do podatnej kontroli hosta. W przeanalizowanych materiałach nie pojawiają się takie dowody.

Organizacje powinny unikać przekształcania ustalenia dotyczącego rodziny procesorów w niepotwierdzone twierdzenie o naruszeniu chmury. Nie powinny też bagatelizować problemu tylko dlatego, że nie ujawniono zdalnego ataku.

Lokalne lub łańcuchowe podatności mogą stać się wartościowymi narzędziami po uzyskaniu początkowego dostępu. Głęboka trwałość ma często największe znaczenie dla zaawansowanych atakujących, którzy już dysponują innymi metodami wejścia.

Największą niewiadomą jest rzeczywisty warunek wstępny ataku

Nierozstrzygnięte pytanie nie dotyczy tego, czy chroniona pamięć ma znaczenie, lecz tego, co atakujący musi kontrolować, zanim Skitter zadziała.

Instrukcja procesora wykonuje się w ramach modelu uprawnień. Niektóre instrukcje działają w zwykłych aplikacjach, podczas gdy inne wymagają uprawnień jądra lub firmware'u.

Ten warunek wstępny określa, czy Skitter jest podatnością umożliwiającą początkowe wejście, czy techniką eskalacji po naruszeniu. Te dwie kategorie wymagają różnych reakcji.

Jeśli nieuprzywilejowany kod może wywołać zmianę mapowania, ekspozycja byłaby wyjątkowo szeroka. Przeglądarki, czytniki dokumentów lub zwykłe usługi mogłyby stać się możliwymi ścieżkami dostarczania poprzez odrębne błędy wykonania kodu.

Jeśli wymagany jest dostęp ring-zero, Skitter rozpoczyna działanie dopiero po tym, jak system operacyjny został już głęboko naruszony. Jego główna wartość dotyczyłaby unikania wykrycia, dostępu do sekretów i trwałości poniżej jądra.

Żadna z interpretacji nie czyni tej wady błahą. Zmieniają one jednak jej pilność, prawdopodobnych atakujących i opcje łagodzenia skutków.

Wcześniejsza technika Memory Sinkhole wymagała uprawnień na poziomie jądra do przeprogramowania rejestru specyficznego dla modelu. Współczesna analiza wskazywała, że złośliwy sterownik mógł zapewnić taki dostęp.

Skitter może wykorzystywać inną instrukcję i inną kontrolę. Czytelnicy nie powinni zakładać identycznych wymagań, dopóki Domas lub AMD nie opublikuje rozstrzygających szczegółów technicznych.

Kolejną niewiadomą jest dokładny zakres dotkniętych rewizji. Rodziny procesorów obejmują wiele modeli, wersji i produktów zintegrowanych.

Dokumentacja AMD zaleca oprogramowaniu identyfikowanie errat na podstawie danych o rodzinie, modelu i rewizji. Oznaczenie obejmujące całą rodzinę może być początkowo użyteczne, ale niewystarczające dla działań naprawczych.

Zależność od firmware'u dodaje kolejną zmienną. Producent płyty głównej może inaczej konfigurować regiony pamięci lub dodawać mechanizmy kontroli, które komplikują wykorzystanie luki.

Wiarygodna macierz testów powinna obejmować wiele systemów desktopowych, mobilnych i wbudowanych. Powinna także porównywać wersje firmware'u oraz domyślne ustawienia bezpieczeństwa.

Na podstawie dostępnych relacji środki zaradcze pozostają niejasne. Aktualizacja mikrokodu mogłaby zablokować odpowiednią kontrolę, lecz tylko AMD może potwierdzić, czy dotknięty sprzęt obsługuje taką naprawę.

Aktualizacja firmware'u mogłaby potencjalnie zablokować ścieżkę wyzwalającą lub monitorować instrukcję. Zależy to od tego, kiedy procesor ocenia kontrolę i jakie funkcje przechwytywania istnieją.

Mechanizmy obronne systemu operacyjnego także mogą pomóc, jeśli atak wymaga sterownika. Listy dozwolonych sterowników, zabezpieczenia oparte na wirtualizacji i kontrole integralności jądra mogą ograniczyć dostęp do uprzywilejowanych instrukcji.

Środki te nie naprawiają wadliwej granicy sprzętowej. Utrudniają atakującym dotarcie do punktu, w którym granica może zostać wyłączona.

Izolacja fizyczna pozostaje przydatna dla systemów, które nie mogą otrzymać poprawek. Kontroler o jednym przeznaczeniu, bez dostępu do sieci, ma mniejszą powierzchnię zdalnego ataku.

Jednak nośniki wymienne, laptopy serwisowe, interfejsy zdalnego zarządzania i aktualizacje dostawców nadal mogą wprowadzać uprzywilejowany kod. „Odizolowany od sieci” powinien opisywać zweryfikowane mechanizmy kontroli, a nie założenie.

Właściciele powinni powstrzymać się od pobierania nieoficjalnych narzędzi proof of concept na systemy produkcyjne. Eksperymenty niskopoziomowe mogą zawiesić komputer, uszkodzić stan lub skomplikować późniejszą analizę kryminalistyczną.

Bezpieczna reakcja zaczyna się od inwentaryzacji. Należy zapisać rodzinę procesora, model, rewizję, płytę główną, wersję firmware'u, system operacyjny i funkcję biznesową.

Następnie należy ustalić, czy urządzenie obsługuje sekrety lub uprzywilejowane obciążenia. Poświadczenia domenowe, materiały do szyfrowania dysku, operacje podpisywania oraz dostęp do sterowania przemysłowego podnoszą stawkę.

Potem należy szukać biuletynu bezpieczeństwa AMD lub komunikatu producenta płyty głównej, który wskazuje odpowiednie modele. Ogólne porady dotyczące aktualizacji nie wystarczą, gdy dostawcy zakończyli wsparcie.

Wyrażenie amazon amd nie powinno kierować działaniami naprawczymi. Powinny je określać dokładna tożsamość sprzętu i autorytatywne wytyczne dostawcy.

Na co właściciele i badacze powinni zwrócić uwagę dalej

Trzy sygnały określą, czy Skitter stanie się praktycznym kryzysem bezpieczeństwa, czy pozostanie ograniczoną techniką po naruszeniu.

Pierwszym sygnałem jest pełne ujawnienie techniczne od Domasa. Powinno ono wskazywać instrukcję, bit kontrolny, warunki wstępne, przetestowane procesory i metodę weryfikacji.

Takie ujawnienie umożliwiłoby niezależnym badaczom odtworzenie zmiany mapowania. Reprodukcja na wielu płytach głównych wzmocniłaby twierdzenie dotyczące całej rodziny.

Ujawniłoby również, czy jedna instrukcja realizuje tylko pierwszy etap. Badacze mogliby wtedy oddzielić usunięcie granicy od wykorzystania PSP, SMM i mikrokodu.

Publiczny proof of concept musi być traktowany ostrożnie. Udostępnienie wystarczającej liczby szczegółów do weryfikacji może również obniżyć koszt uzbrojenia tej techniki przeciwko niewspieranym systemom.

Drugim sygnałem jest odpowiedź AMD w zakresie bezpieczeństwa produktów. Właściciele potrzebują biuletynu zawierającego listę dotkniętych modeli, poziom istotności, warunki wstępne, środki łagodzące oraz dostępne aktualizacje firmware'u lub mikrokodu.

AMD wcześniej publikowało komunikaty dotyczące fTPM, które rozróżniają dotknięte wersje firmware'u i kroki łagodzące. Jego wytyczne fTPM pokazują poziom szczegółowości potrzebny do użytecznej odpowiedzi.

Biuletyn wyjaśniłby również, czy nowsze rodziny odziedziczyły jakąkolwiek część mechanizmu. Obecne relacje ograniczają Skitter do Family 15h i 16h.

Ten zgłoszony limit wyklucza procesory Ryzen i EPYC oparte na Zen, chyba że późniejsze dowody rozszerzą zakres. Czytelnicy nie powinni uogólniać tego twierdzenia na wszystkie procesory AMD.

Oświadczenie AMD mogłoby osłabić obecną ocenę, jeśli bit jest niedostępny w obsługiwanych konfiguracjach. Wzmocniłoby ją, gdyby firma potwierdziła szeroką ekspozycję modeli.

Trzecim sygnałem jest działania naprawcze dostawców dla maszyn, które nadal są wdrożone. Producenci płyt głównych i dostawcy systemów wbudowanych kontrolują dostarczanie firmware'u dla wielu dotkniętych produktów.

Poprawka na poziomie procesora ma ograniczoną wartość, jeśli właściciele urządzeń nie mogą uzyskać jej w podpisanym, możliwym do wdrożenia pakiecie firmware'u. Starsze płyty konsumenckie wiążą się z największą niepewnością wsparcia.

Dostawcy systemów wbudowanych mogą stanąć przed dłuższymi zobowiązaniami lub żądaniami klientów dotyczącymi aktualizacji. Ich reakcja pokaże, ile dotkniętych platform pozostaje istotnych operacyjnie.

Przedsiębiorstwa powinny jednocześnie monitorować własną inwentaryzację. Liczba narażonych maszyn ma większe znaczenie niż zainteresowanie wyszukiwaniem wokół ofert amazon amd.

Zespoły ds. bezpieczeństwa mogą zacząć od nieinwazyjnej identyfikacji. Powinny unikać wykonywania nieudokumentowanych instrukcji na sprzęcie produkcyjnym, dopóki szczegóły techniczne pozostają niepełne.

Zespoły zakupowe powinny oznaczać systemy Family 15h i 16h oferowane do ponownego wykorzystania. Niska cena zakupu nie rekompensuje problemu z nieusuwalną izolacją sprzętową.

Używane systemy nadal mogą służyć w kontrolowanych środowiskach badawczych. Nie powinny jednak otrzymywać wrażliwych ról tylko dlatego, że ich wydajność wciąż jest wystarczająca.

Zespoły reagowania na incydenty powinny uwzględniać głębsze warstwy podczas badania podejrzanej maszyny, której problem może dotyczyć. Czysty skan systemu operacyjnego nie może potwierdzić, że stan SMM lub oprogramowania układowego jest godny zaufania.

Ponowna instalacja systemu operacyjnego może również dawać niepełną pewność. Decyzje dotyczące odzyskiwania powinny opierać się na potwierdzonych informacjach o trwałości zagrożenia i zapisywalnej pamięci masowej.

Dla większości indywidualnych właścicieli nie ma podstaw do natychmiastowej paniki. Doniesienia nie wskazują na szeroko zakrojoną zdalną kampanię, naruszenie bezpieczeństwa Amazon ani automatyczne wykorzystanie luki podczas zwykłego przeglądania internetu.

Dalsze korzystanie z urządzenia nadal wymaga weryfikacji, gdy przechowuje ono ważne poświadczenia lub nie ma wsparcia dla oprogramowania układowego. Wymiana staje się rozsądnym środkiem bezpieczeństwa, gdy weryfikacja jest niemożliwa.

Odpowiedzialny kolejny krok jest prosty: precyzyjnie zidentyfikuj procesor, śledź podstawowe materiały techniczne i stosuj się do wskazówek producenta dotyczących konkretnego modelu. Traktuj wyniki wyszukiwania na platformach handlowych jako tropy, a nie dowody.

Trwała lekcja płynąca ze Skittera nie brzmi, że każdy stary komputer AMD jest skompromitowany. Chodzi o to, że niewielki mechanizm kontroli architektury może mieć większe uprawnienia niż warstwy widocznego oprogramowania zabezpieczającego.

Jeśli Twoja inwentaryzacja obejmuje sprzęt Family 15h lub 16h, czy potrafisz dziś określić jego dokładny model, status oprogramowania układowego oraz dostęp do wrażliwych systemów?

Udokumentuj te odpowiedzi przed rozpoczęciem jakichkolwiek testów. Następnie porównaj każdą maszynę z nadchodzącymi ujawnieniami od Domas, AMD oraz producenta jej płyty głównej lub systemu wbudowanego.

Dla czytelników, którzy trafili tu przez wyszukiwanie amazon amd, kluczowe rozróżnienie pozostaje istotne. Jest to zgłoszony problem z izolacją procesorów AMD, a nie potwierdzony incydent bezpieczeństwa Amazon.