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.
