Meltdown i Spectre: Wpływ błędów w procesorach na bezpieczeństwo IoT

Wstęp

Bezpieczeństwo systemów było zazwyczaj traktowane jako kwestia istotna jedynie dla środowiska IT, począwszy od korporacji, a kończąc na komputerach domowych i raczej rzadko poważnie się nad tym zastanawiano w świecie systemów wbudowanych. Obecnie szybko się to zmienia ze względu na rozwój Internetu Rzeczy (IoT – Internet of Things) i wzrastającej wagi systemów wbudowanych w aplikacjach krytycznych z punktu widzenia bezpieczeństwa. W ubiegłym roku problem ten został uwidoczniony przy okazji pojawienia się wirusa Mirai, który zainfekował cyfrowe rejestratory wideo i inne niezbyt ważne, ale podłączone do Internetu urządzenia. Atak nie powodował uszkodzenia żadnych konkretnych funkcji tych urządzeń. Nadal pracowały tak jak wcześniej, ale dodatkowo służyły identyfikacji i zarażaniu kolejnych urządzeń, a następnie zostały wykorzystane do ataków DDoS (Distributed Denial of Service), które spowodowały zamknięcie lub dramatyczne spowolnienie niektórych serwisów internetowych. Ponieważ wiele z tych rejestratorów i powiązanych z nimi kamer znajdowało się w instalacjach systemów bezpieczeństwa, nie potrzeba nawet wyjątkowej pomysłowości, by wyobrazić sobie jak zainfekować je i następnie wykorzystać do innych celów. Mirai rozkwitł, a jego nowe odmiany wciąż dobrze funkcjonują, ponieważ miliony urządzeń jest dostarczanych z domyślnymi ustawieniami bezpieczeństwa, które w praktyce stanowią otwarte drzwi dla wścibskiego oprogramowania.

Mirai korzystał z Internetu i protokołu IP by dostać się do podłączonych urządzeń, ale możliwe jest także użycie innych kanałów komunikacji, takich jak np. Bluetooth. Armis - firma zajmująca się bezpieczeństwem w IoT, zidentyfikowała osiem podatności w stosie protokołu Bluetooth, które odpowiadają za komunikację w wielu urządzeniach mobilnych. Zostały one zbiorczo nazwane mianem BlueBorne oraz omówione w innym artykule na temat bezpieczeństwa IoT: „Walka Bluetootha z hakerami nasila się.”

Staje się oczywistym, że hakerzy to już nie tylko niedostosowani do społeczeństwa, młodzi mężczyźni, działający ze swoich sypialni, ale zorganizowane grupy, które posługują się wyrafinowanymi technologiami. Niektóre z nich mogą być po prostu grupami przestępczymi, podczas gdy inne – organizacjami działającymi na zlecenie państw. Znanym faktem jest to, że Rosja wykorzystuje dużo różnej broni cyfrowej przeciw Ukrainie, wliczając w to atak, w ramach którego zatrzymano pracę sieci elektrycznej w kraju. Wiele z ataków koncentruje się na słabości oprogramowania i socjotechnikach. Jednakże te zorganizowane grupy coraz bardziej zwracają uwagę na IoT i przemysłowy Internet Rzeczy, gdzie zbieranie i transmisja danych odbywają się często bez jakichkolwiek interakcji z człowiekiem. Dane te mogą posłużyć do zdobycia cennych informacji na temat działania firmy, co następnie da się wykorzystać do zdobycia przewagi na rynku, lub do spowodowania uszkodzeń – np. poprzez zmienienie przesyłanych informacji i wymuszenie pracy urządzeń z innymi parametrami niż założone. Takie ataki mogą powodować duże straty finansowe.

To właśnie z tego powodu, wykrycie dwóch luk sprzętowych, Meltdown i Spectre, jest tak niepokojące.

Meltdown i Spectre

Czym są Meltdown i Spectre?

Większość problemów związanych z bezpieczeństwem, z jakimi mierzą się obecnie firmy na całym Świecie, wiąże się z wykorzystaniem słabości oprogramowania systemów. Istnieją również ataki, które korzystają z informacji zebranych np. z fizycznej implementacji systemu. Tego typu metody mogą np. zbierać informacje o taktowaniu, zużyciu mocy, lub o „wyciekających” falach elektromagnetycznych, by zrozumieć co dzieje się w analizowanym systemie. Meltdown i Spectre idą znacznie dalej, gdyż wykorzystują określone aspekty architektury wydajnych procesorów, by zdobyć informacje prosto z uruchomionych aplikacji. Takie elementy architektury zostały zastosowane w wielu nowoczesnych procesorach firm Intel i AMD oraz w rdzeniach ARM i odnoszą się do tzw. kieszeniowania (caching) i wykonywania spekulatywnego.

Prosty pseudoprogram mógłby wyglądać następująco:

• t = a+b
• u = c+d
• v = e+f
• w = v+g
• x = h+i
• y = j+k

W komputerze o klasycznej architekturze, zwykły (skalarny) procesor, taki jak Intel 486 albo ARM 1178 wykona jedną instrukcję w każdym cyklu zegarowym. Oznacza to, że 6 powyższych instrukcji zajmie 6 cykli.

Aby zwiększyć wydajność w takich systemach, należało po prostu przyspieszyć zegar taktujący. Jednakże to prowadzi do dwóch problemów. Po pierwsze, możliwość przyspieszania działania bramek logicznych jest ograniczona, a po drugie czasy odczytu i zapisu danych, z i do pamięci, były znacznie wolniejsze niż czas przetwarzania przez procesor. Alternatywą do zwiększania szybkości zegara procesora jest sprawienie by procesor przetwarzał więcej niż jedną instrukcję w tym samym czasie, tworząc tzw. procesor superskalarny. Jeśli mamy dwupotokowy procesor, wtedy będzie on wykonywał instrukcje parami, jednocześnie. Ten sam pseudokod będzie wtedy wyglądał następująco:

• t, u = a+b, c+d
• v, w = e+f, v+g
• x, y = h+i, j+k

I w teorii, jego wykonanie zajmie połowę czasu względem zwykłego procesora.

Jednakże przyjrzenie się kodowi pozwala zauważyć pewne problemy. Druga para instrukcji nie może zostać wykonana jednocześnie, gdyż najpierw trzeba obliczyć wartość v, by można było ją użyć do obliczenia wartości w. Drugi potok musi poczekać na zakończenie pracy potoku pierwszego w następujący sposób:

• t, u = a+b, c+d
• v = e+f            # drugi potok w tym czasie nic nie robi
• w, x = v+g, h+i
• y = j+k

W rezultacie kod wykonuje się przez cztery cykle zamiast trzech, co wciąż jest usprawnieniem względem oryginalnego kodu.

Jednak jeśli zależność w kodzie dotyczy jedynie w i v, można zmienić kolejność wykonywania instrukcji dla obliczenia wartości w i x, co pozwoli uzyskać następujący kod:

• t, u = a+b, c+d
• v, x = e+f, h+i
• w, y = v+g, j+k

Jest to optymalnie ułożony zestaw instrukcji do wykonania za pomocą dwóch potoków. Przykładami procesorów superskalarnych, które stosują taką optymalizację kolejności wykonania kodu jest większość procesorów x86 Intela i AMD, począwszy od Pentium 2 wzwyż, oraz najnowsze rdzenie ARM.

W rzeczywistości programy są bardziej skomplikowane niż powyższy, krótki zestaw poleceń. Największą różnicą jest to, że zawierają instrukcje skoków. Te mogą być bezwarunkowe (zawsze wykonywane), lub warunkowe (zależne od obliczonej wartości). Mogą być skokami wprzód (komendy „if”), lub wstecz (pętle). Mogą być określone bezpośrednio – do jawnie wskazanego adresu, lub pośrednio – do adresu zapisanego w rejestrze, miejscu pamięci, lub na stosie procesora.

Aby wykonanie kodu nie spowalniało zbytnio w momencie napotkania na skok, procesory korzystają z mechanizmów predykcji skoków, które bazują na statystyce z poprzednich skoków, dzięki czemu są w stanie zgadywać, czy skok zostanie wykonany czy nie. Inną techniką, stosowaną przy przetwarzaniu w trzech lub czterech potokach jest działanie spekulatywne. Polega ono na próbie zgadnięcia, które instrukcje będą potrzebne i następnie wykonaniu ich. Jeśli w rzeczywistości nie będą użyte, np. jeśli skok sprawił że nie są potrzebne, wtedy obliczone rezultaty zostają zignorowane. Z pomocą predyktora skoków, który wskazuje najbardziej prawdopodobną ścieżkę wykonania kodu, praca spekulatywna może spowodować znaczny wzrost szybkości działania programu.

Jednakże tak jak wspomnieliśmy wcześniej, pamięć nie nadąża za szybkością wykonywania kodu. Aby pokonać ten problem, projektanci procesorów korzystają z pamięci cache, a więc małych kieszeni, w których przechowują podobszary pamięci już w układzie procesora. Zawierają one kopie lokacji głównej pamięci, które były niedawno w użyciu lub te, które są w pobliżu adresów niedawno używanych, jako że istnieje duże prawdopodobieństwo, że będą niedługo potrzebne.

Mając na uwadze powyższe mechanizmy, istnieją dwie rzeczy, które osoba atakująca może wykorzystać. Pierwsza z nich to mechanizm predykcji skoków, który można nauczyć by podawał błędne przewidywania. A jeśli zmierzony zostanie czas potrzebny na dostęp do pamięci, da się sprawdzić, czy wybrany adres znalazł się w kieszeni czy nie.

Posiadając te informacje, osoba wykorzystująca atak Meltdown jest w stanie odczytać informacje zapisane w jądrze systemu operacyjnego, podczas gdy atak Spectre może odczytać zawartość pamięci innego działającego programu, która powinna być dla niego niedostępna.

Ilustracja 1.: Kluczowa sekwencja instrukcji ataku Meltdown

Aby dostać się do atakowanego sprzętu, hakerzy mogliby wykorzystać prosty program javascriptowy. W przypadku systemu, w którym uruchomiona jest przeglądarka internetowa (np. na telefonie lub w tablecie), wystarczy po prostu odwiedzić zainfekowaną stronę internetową. Inne urządzenia, takie jak węzły IoT mogą zostać zaatakowane przez złośliwy kod, przeglądający sieć w poszukiwaniu słabo chronionych urządzeń, tak samo jak działał Mirai. Po dokonaniu ataku Meltdown lub Spectre nie pozostaje żaden dowód, że zabezpieczenia systemu zostały złamane.

Pomimo dużej uwagi poświęconej Meltdown i Spectre przez media, nie ma znanych przypadków udanych ataków tego typu.

Kto jest zagrożony?

Meltdown stanowi problem głównie w procesorach Intela. Każdy procesor tej firmy, począwszy od 1995 roku jest podatny, za wyjątkiem układów Itanium i niektórych procesorów serii Atom. Firma ARM poinformowała, że także rdzeń Cortex A-75 jest podatny. Spoglądając poza rynek systemów wbudowanych, warto zwrócić uwagę na to, że firma Apple poinformowała, że większość jej produktów jest także wrażliwa na ten atak i w związku z tym wypuszczono poprawki dla systemów operacyjnych.

Spectre jest nieco bardziej rozpowszechnionym zagrożeniem, gdyż dotyczy wielu procesorów Intela i AMD. Co więcej narażone są też układy z rdzeniami ARM Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73 i Cortex-A75. Rdzenie te są podstawowymi elementami wielu procesorów, najczęściej stosowane rdzenie w systemach wbudowanych i w IoT należą do serii Cortex-M, który nie jest podatny na atak Spectre. Firma ARM zaznacza też, że rdzenie Cortex-R są najczęściej stosowane w zamkniętych systemach, do których zazwyczaj ewentualny napastnik nie będzie miał dostępu.

Raspberry Pi nie wykorzystuje żadnych z podatnych rdzeni (Raspberry Pi 3 i nowsze Raspberry Pi 2 bazują na układzie Broadcom BCM2837, który wyposażono w rdzeń ARM Cortex-A53), a więc jest niewrażliwe zarówno na Spectre i Meltdown.

Biorąc pod uwagę dostępne obecnie płytki komputerów, obraz rynku jest mniej jednolity. Wybór płytki do projektowanego rozwiązania zazwyczaj polega na dobraniu jej pod kątem wydajności i funkcji, w odniesieniu do potrzeb aplikacji i nadal będą to kluczowe kryteria podczas podejmowania decyzji. Jednakże projektanci mogą preferować płytki, które są mniej podatne na omówione zagrożenia, zamiast samodzielnie starać się stosować jakieś zabiegi, które zmniejszą ryzyko i konsekwencje ataku.

Łagodzenie problemów

Od pojawienia się pierwszych doniesień na temat zagrożeń, zaproponowano masę potencjalnych sposobów złagodzenia problemów. Ich autorami byli zarówno producenci układów, firma ARM, jak i twórcy systemów operacyjnych. Autorzy najbardziej popularnych systemów operacyjnych wypuścili poprawki, które albo częściowo ograniczają skutki ataków, albo je całkowicie powstrzymują. Firmy zajmujące się tworzeniem oprogramowania antywirusowego również zaktualizowały swoje produkty, by pomóc w powstrzymaniu działań, które mogłyby wywołać takie ataki.

Osoby zajmujące się sprzętem także wprowadziły modyfikacje w swym mikrokodzie, ale problem z Meltdown i Spectre polega na tym, że ataki te wykorzystują konsekwencje decyzji projektowych, których celem było przyspieszenie wydajności pracy systemów. Próba uodpornienia urządzeń na te problemy powoduje spowolnienie procesorów. Początkowe komentarze prasowe sugerowały, że spadek wydajności może być bardzo znaczący i sięgnąć 25%. W późniejszym okresie zrewidowano te estymacje, ale sytuacja jest i tak mglista przez firmę Intel, która musiała przygotować oddzielne poprawki dla poszczególnych rodzin procesorów, w efekcie czego, w momencie pisania tego artykułu, nie ma jeszcze szacunków co do spodziewanego spadku wydajności dla tych modyfikacji. Innym problemem jest, że wielu komentatorów oraz testerów pracujących nad tym tematem to osoby koncentrujące się na komputerach PC i systemach IT, a nie zajmujące się pomiarem wpływu zmian na systemy wbudowane.

Jest także kilka poprawek dostarczonych przez ARM, które są powiązane z systemem operacyjnym. I w tym przypadku także nie jest jasne, jaki wpływ na wydajność będzie miało zastosowanie tych poprawek.

Produkty oparte o systemy wbudowane często pracują w czasie rzeczywistym. I niestety, w przypadku twórców systemów RTOS nie ma jeszcze stosownych komentarzy odnośnie spodziewanego spadku wydajności. Wyjątek stanowi jedna firma, która poinformowała, że ich system czasu rzeczywistego jest odporny na omawiany problem. Twórcy systemów wbudowanych często wybierają procesor poprzez precyzyjne balansowanie zużyciem energii i wydajnością, tak by układ pracował blisko swoich maksymalnych możliwości, zapewniając wymaganą wydajność. Nawet najmniejszy spadek wydajności może więc doprowadzić do sytuacji, gdzie ich aplikacja przestanie działać.

Co powinni zrobić inżynierowie IoT?

W przypadku IoT istnieje, w uproszczeniu, kilka punktów do rozważenia. Jeden to urządzenia końcowe, w których informacje są zbierane, czy które sterują działaniem innych urządzeń. Drugi to bramki, które zbierają dane z różnych urządzeń i przekazują je do sieci. Trzeci to procesory sieciowe, a czwarty obejmuje serwery w chmurze. W przypadku firm z serwerami, takich jak Amazon, trwają intensywne prace nad dalszym poprawieniem izolacji pomiędzy poszczególnymi użytkownikami i zapewnieniem innych zabiegów na rzecz bezpieczeństwa. W ogólności, procesory urządzeń ethernetowych nie są podatne na ataki Meltdown ani Spectre. Potencjalne ryzyko stanowią bramki, przy czym większość tego, co można powiedzieć na temat urządzeń końcowych, dotyczy też samych bramek.

Przyglądając się właśnie urządzeniom końcowym w IoT można zaobserwować dwa problemy. Pierwszy dotyczy produktów już zainstalowanych, a drugi produktów wdrażanych w przyszłości.

Wiele wdrożonych już produktów IoT korzysta z procesorów z „dolnej półki”, z rdzeniami Cortex-M. W ich przypadku nie ma zagrożenia żadnym z tych ataków. Niezależnie od procesora byłoby rozsądnym przeprowadzić audyt obejmujący wszystkie zainstalowane produkty i ocenić ich podatność, wliczając w to ryzyko ataku i zadecydować, czy potrzebne jest wprowadzenie jakichkolwiek poprawek. Firmy dostarczające takie urządzenia powinny również przemyśleć strategię radzenia sobie z tego typu problemami w przyszłości, jako że można mieć niemal pewność, że kolejne podatności będą odkrywane w procesora, układach komunikacyjnych i całych produktach IoT.

W przypadku nowych produktów konieczne jest uwzględnienie odpowiedniego poziomu bezpieczeństwa już w wymaganiach projektowych. (Z ankiety Barr Group, przeprowadzonej w 2018 roku wynikło, że mniej niż 22% projektów IoT w 2017 roku obejmowało odpowiednie zabezpieczenia.) I nawet pomimo dołożenia wszelkich starań podczas projektowania i implementacji, zawsze istnieje ryzyko pojawienia się nowych problemów, co oznacza że już początkowe wymogi projektowe powinny obejmować metody na obchodzenie tych trudności i aktualizację już zainstalowanych urządzeń.

Ponieważ wdrażanie poprawek do pracujących urządzeń jest kosztowne, a wypuszczanie płytek do podmiany jest jeszcze bardziej drogie, będzie znacznie tańszym zainwestowanie dodatkowej ilości czasu i starań w zbudowanie odpornego i bezpiecznego systemu już na początku. Nawet małe działania, takie jak wymuszenie zmiany hasła przy pierwszym użyciu, lub po jego zresetowaniu do hasła fabrycznego ograniczy podatność urządzenia. A by to zrobić, wystarczy tylko kilka linijek kodu i można zabezpieczyć urządzenie przed takimi popularnymi hasłami jak „123456” czy „asdgfg”. Należy też dobrze się przyjrzeć temu, do których elementów systemu dostęp jest faktycznie potrzebny. Można także rozważyć zastosowanie różnych poziomów bezpieczeństwa dla różnych wykonywanych zadań.

Obecnie, do czasu gdy dla podatnych procesorów zostaną wypuszczone aktualizacje oprogramowania, które powstrzymają ataki Meltdown i Spectre, przyjrzyj się alternatywnym ścieżkom postępowania. Stosuj dobre praktyki programistyczne i narzędzia, które pozwalają tworzyć wysokiej jakości kod. W końcu, spodziewaj się, że niebawem odkryty zostanie nowy problem, którego jeszcze nie znamy.

Meltdown i Spectre: Wpływ błędów w procesorach na bezpieczeństwo IoT. Data publikacji: 15 marca 2018 r. przez Farnell