Meltdown i Spectre spotkały się z dużym rozgłosem w mediach. Jedno z pytań, jakie spędzało sen z powiek użytkownikom oraz operatorom centrów danych, dotyczyło skutków zastosowania opracowanych środków zaradczych. Chodziło konkretnie o to, dlaczego i do jakiego stopnia wydajność wzięła górę nad bezpieczeństwem. Czy jednak „pożar” został ugaszony i nigdy nie dojdzie do podobnych sytuacji? Jak się okazuje, niekoniecznie.
Z wielu raportów wynika, że od lat dziewięćdziesiątych nie wprowadzono większych zmian w strukturach procesorów, a nawet, że wcale ich nie modernizowano. W celu zwiększenia wydajności procesorów firmy Intel, AMD oraz Cyrix stworzyły i zastosowały mechanizm zwany wykonywaniem spekulatywnym. W porównaniu ze starszymi procesorami model ten wykazuje przewagę w kilku aspektach, w szczególności, jeśli chodzi o wydajność.
Ścisły związek – od narzuconych do aktualizowanych instrukcji
Podejmując temat sprzętu samego w sobie, automatycznie wychodzimy poza ramy świata opartego na oprogramowaniu, w którym przyszło nam wszystkim żyć. Niemal wszystko, co robimy, wiąże się z wykorzystywaniem oprogramowania. Sam procesor niewiele jednak zdziała w kwestii oprogramowania, dlatego że większość programów napisano w języku programowania będącym na „wyższym poziomie” (np. C, C++, C#, Java etc.), który jest czytelny i bardziej zrozumiały dla człowieka. Procesor posługuje się za to zupełnie innym językiem nazywanym „mikro kodem”. „Słownictwo” tego języka przechowywane jest w przeznaczonej do tego celu sekcji procesora. Tę sekcję pamięci można edytować tak, by uzyskać optymalizację działań rutynowych lub naprawić błędy. Inaczej niż w procesorach starszego typu, takich jak 8-bitowy MOS 6502, zestawy instrukcji były narzucane dla chipów danego typu i nie było możliwości ich wymiany w późniejszym czasie. Z tego powodu rozwiązywanie problemów i opracowywanie strategii zaradczych jeszcze na etapie tworzenia to nie lada wyzwanie. A w przypadku wykrycia błędu już po sprzedaży, jednym ze sposobów poradzenia sobie z nim było wyprodukowanie kosztownej aktualizacji produktu oraz wymiana całego procesora.
Do lat osiemdziesiątych i początku dziewięćdziesiątych wiele programów pisano w Assemblerze, ponieważ inne języki programowania nie zostały jeszcze wynalezione lub na tamtym etapie nie były wystarczająco wydajne do tego typu pracy. Z kolei Assembler w swoim działaniu jest podobny do samego sprzętu IT, co umożliwiało zwiększenie wydajności, zachowując przy tym charakter zrozumiały dla człowieka. Z reguły można przetłumaczyć instrukcje Assemblera bezpośrednio na mikro kod.
Możliwość wykorzystania aktualizowalnego mikro kodu bardzo ułatwiła stworzenie nowych procesorów: nie było konieczności projektowania nowych obwodów, co obniżyło koszty, zaowocowało oszczędnością czasu i wzrostem wydajności.
Ocena ryzyka
Możliwości wykorzystania tricków opartych na oprogramowaniu do uzyskania dostępu do pamięci wewnętrznej procesora, gdzie przechowywane są kluczowe informacje, nigdy nie uważano za czynnik ryzyka. Taka operacja wymaga wiedzy na temat działania wnętrza procesora i nie każdy potrafiłby je zaplanować. Tego typu atak funkcjonował jako akademicki twór teoretyczny przez jakiś czas, ale dalej się nie rozwinął.
Problem tkwi w tym, że wszystkie obecnie występujące scenariusze zagrożeń kiedyś funkcjonowały w sferze akademickiej teorii – do momentu, aż ktoś wprowadził je w życie.
Meltdown i Spectre nauczyły producentów chipów jeszcze jednej rzeczy: komunikacja wewnątrz procesora wymaga odpowiedniego poziomu zabezpieczeń. Ich brak można oczywiście obrócić przeciwko producentom, ale to droga na skróty.
To nie takie proste
Rejestratory parametrów lotu („czarne skrzynki”) stały się obowiązkowym elementem wyposażenia samolotów pasażerskich po kilku poważnych katastrofach.
Można by wyciągnąć wniosek, że istnieje możliwość stworzenia sprzętu wolnego od błędów, który nie wymagałby dalszych ulepszeń. W praktyce tak to jednak nie wygląda i nigdy nie wyglądało. Inne sektory przemysłu podają wiele podobnych przykładów. Przyjrzyjmy się na przykład lotnictwu: niektórych elementów nigdy nie poddawano powtórnej analizie, ponieważ do danego momentu działały prawidłowo i nigdy nie sprawiały problemów. Dopiero później zorientowano się, że mogą one stwarzać problemy i wymagają przeprowadzenia zmian.
Oto przykład:
Okna w samolotach nie bez powodu mają mniej lub bardziej okrągły kształt albo przynajmniej zaokrąglone krawędzie. W tej historii należy cofnąć się do de Havilland Comet, jednego z pierwszych samolotów pasażerskich po drugiej wojnie światowej. Początkowo miał on duże kwadratowe okna, takie jak od dziesięcioleci stosowano w samochodach, pociągach lub starszych samolotach. Kwadratowe okna przyjmowano jako bezpieczne rozwiązanie, ponieważ nie było ku niemu znanych przeciwwskazań. Po kilku katastrofach okazało się jednak, że w samolotach z kabinami ciśnieniowymi, które w tamtym czasie stanowiły nowość, kwadratowe okna to źródło zagrożenia. Dokładne badania pokazały, że różnice ciśnień skutkowały zwiększonym naciskiem i zużyciem metalu w rogach drzwi i okien, co natężało się wraz z upływem czasu i przedłużonym oddziaływaniem ciśnienia. Materiał w narażonych miejscach z czasem ulegał zniszczeniu, aż dochodziło do katastrofy – następowała szybka dekompresja, fatalna w skutkach dla integralności struktury całego samolotu.
Po odnalezieniu źródła problemu we wszystkich nowych samolotach zaczęto stosować ulepszone rozwiązania i dziś zaokrąglone rogi okien samolotu to norma. Tego typu historie miały wpływ nie tylko na kształt okien samolotów. Z podobnego powodu wszystkie samoloty pasażerskie muszą być wyposażone w „czarną skrzynkę” nagrywającą parametry lotu (która w rzeczywistości nie jest wcale czarna, ale jasnopomarańczowa). Kolejne przykłady można by mnożyć w nieskończoność, a jednym z nich jest magistrala CAN stosowana w pojazdach, której stworzenie nie wiązało się wcale z myślą o „świecie połączeń”. Zasada pozostaje taka sama: to, co na początku nie stanowiło źródła problemu, okazało się zagrożeniem, wprowadzono więc zmiany i historia toczyła się dalej.
Sytuacja będzie przedstawiała się w ten sam sposób, jeśli chodzi o Meltdown i Spectre. Swoją drogą nie są to jedyne problemy, jakie wykryto w procesorach i zgłoszono. Istniało na przykład coś takiego, jak tak zwany błąd F00F, który ujrzał światło dzienne w połowie lat dziewięćdziesiątych. W tamtych czasach można było mu zaradzić, wprowadzając zmiany w systemie operacyjnym. Bez wymaganej łatki zainfekowane urządzenie przestawało działać, a utraty danych nie dawało się w zasadzie uniknąć.
W kwestii aktualizacji mikro kodu producenci powinni zachować ostrożność. Kompatybilność wsteczna ma negatywny wpływ na wiele aspektów procesu rozwoju mikro kodu. Staje się to jeszcze ważniejsze, gdy weźmiemy pod uwagę sprzęt komponentów kluczowej infrastruktury. Opracowana naprędce łata to ostatnie z rozwiązań, jakiego oczekiwaliby zarówno klienci, jak i producenci. Planowane aktualizacje mikro kodu prawdopodobnie i tak ukażą się z opóźnieniem – Intel niedawno ogłosił, że jedna z łat dla „Spectre” zostaje anulowana, ponieważ w niektórych systemach powodowała nieuzasadnione ponowne uruchomienia.
Co mogą zrobić klienci, którzy ponieśli straty?
Przyjmijmy, że w twoich urządzeniach wystąpił błąd zabezpieczeń. Dotyka on w zasadzie wszystkich procesorów wyprodukowanych po 1995 roku. Zaradzić tej sytuacji można obecnie jedynie poprzez instalowanie aktualizacji dostarczanych dla systemów operacyjnych.
By móc w przyszłości reagować na podobne incydenty, firmy powinny opracować wydajną strategię zarządzania łatami. Należy pilnować, by kluczowe aktualizacje były w firmowych sieciach przeprowadzane na czas.
– Użytkownicy i administratorzy muszą mieć pewność, że instalowane aktualizacje pochodzą z zaufanych źródeł – tłumaczy Robert Dziemianko z G DATA. – Pojawiły się już przykłady złośliwego oprogramowania, które próbowało wykorzystywać zaniepokojenie wśród użytkowników i udawało łatę do zainstalowania do ochrony przed Spectre/Meltdown. W rzeczywistości przekształcała ona komputer, na którym została uruchomiona w część botnetu – dodaje ekspert z G DATA.
Intel mógł obiecać opracowanie aktualizacji mikro kodu dla procesorów stworzonych po 2013 roku. Logiczne jest także wprowadzanie zmian w procesorach tak, by zaradzić pojawiającym się problemom. Pozostaje jednak pytanie, do jakiego stopnia nowe procesory będą podatne na ataki.
Obecnie wiele firm przetwarza dane z zewnętrznych źródeł. Warto o tym pamiętać, ponieważ w tego rodzaju danych może zostać ukryty podejrzany kod. Dlatego też należy za każdym razem sprawdzać, czy w związku z nowo zakupionym sprzętem występują problemy z zabezpieczeniami, a jeśli tak, natychmiast instalować dostępne łaty. Jest to szczególnie ważne, ponieważ powszechne zainteresowanie takimi błędami w zabezpieczeniach, jak na przykład Meltdown dość szybko mija i jest ryzyko, że o nim zapomnimy.
Za każdym razem, gdy mamy do czynienia z przetwarzaniem danych z zewnątrz należy wziąć pod uwagę to, na ile zaufane jest źródło, z którego dane pochodzą i w jaki sposób chronić się przed zakrojonymi na szeroką skalę konsekwencjami przejęcia kontroli nad danymi.
Włamanie się do systemu poprzez dane, które są w systemie przetwarzane to również nic nowego: udało się to w przypadku maszyn do sekwencjonowania DNA, które miały za zadanie przetworzyć specjalnie przygotowaną próbkę. Ten konkretny scenariusz przebiegu ataku (jak na razie?) nie ma odniesienia do rzeczywistości, ale udowodniono, że istnieje taka możliwość. Tak, jak już wspomniano, wszystkie te ataki z początku wydają się czystą teorią, jednak tylko do momentu, gdy ktoś zdecyduje się wcielić je w życie.
