with Brak komentarzy

Meltdown i Spectre nie są groźne dla…

Nie da się przejść obojętnie obok szumu medialnego wywołanego ujawnieniem „dziur” w procesorach Intel, AMD i ARM. A przynajmniej ja tego nie potrafię zrobić. Dlaczego? Błąd w architekturze wykryty został w procesorach, które weszły na rynek po roku 2010. W oświadczeniach publikowanych przez Google można znaleźć informacje o tym, że na ataki narażone są układy Intela, produkowane już po 1995 roku (z wyjątkiem procesorów Intel Itanium i Intel Atom sprzed 2013). To dość spora ilość systemów i urządzeń, zarówno w naszych domach, jak i w przedsiębiorstwach i organizacjach. Nie sądzisz?

Są jednak wśród tych systemów i takie, które mimo iż posiadają wadliwe procesory, to nie są podatne na ataki i nie wymagają aplikowania łatek. Masz już jakiś pomysł co to może być?

Chodzi o obiektowe pamięci masowe (*).

Ale zaraz, dlaczego tam powyżej znalazła się ta "gwiazdka" (*). Już wyjaśniam.

Ponieważ:

  • nie mogę (i nie chcę) wypowiadać się za wszystkich producentów obiektowych pamięci masowych,
  • nie mam zamiaru poświadczać w ich imieniu,
  • nie znam wszystkich tych urządzeń na tyle dobrze i „od kuchni”, aby móc z pełną odpowiedzialnością zapewnić Cię, że dla nich wszystkich będzie miała zastosowanie opisana w dalszej części artykułu prawda.

I dlatego właśnie dzisiaj opowiem Ci o jednym konkretnym rozwiązaniu. A jeżeli wiesz, gdzie aktualnie pracuję, to pewnie już się domyślasz, o którą macierz obiektową chodzi.

Wszystkie poniższe rozważania będą dotyczyły produktu Hitachi Content Platform (HCP).

Rozwiązanie to nie jest podatne na ataki Meltdown i Spectre oraz nie wymaga aplikowania łatek, które jak możesz przeczytać w wielu artykułach w Internecie, potrafią spowolnić działanie procesorów. A za chwilę dowiesz się, dlaczego tak jest.

Kryzys i Zjawa. Czy jest się czego bać?

Po pierwsze.

Coraz więcej producentów, w tym również dostawców chmur, publikuje listy swoich produktów i usług wraz z informacją, które z nich są podatne na ataki. Jeżeli chcesz sprawdzić czy rozwiązania, z których korzystasz w swojej organizacji należą do tej grupy, to polecam odszukać taką listę bezpośrednio u producenta.

 

Po drugie.

Nie jest moją intencją opisywanie szczegółów technicznych o trzech ujawnionych podatnościach. Informacje o nich znajdziesz między innymi tutaj: 

 

Podatności te mogą być wykorzystane do zrealizowania dwóch typów ataków, opisanych tutaj i nazwanych: Meltdown (Kryzys) i Spectre (Zjawa).

 

Polskie nazwy są moim pomysłem. Daj mi znać, jeżeli wiesz, że zdążyły się już przyjąć jakieś inne. 

 

Moim zdaniem bardzo zwięzły i konkretny zastrzyk wiedzy w temacie znajdziesz również w artykułach publikowanych na portalu Niebezpiecznik, m.in w tych dwóch artykułach:

 

Po trzecie.

Pozwolę sobie na krótkie streszczenie tego, co znajdziesz na stronach wymienionych powyżej. Trzy zdania na temat skutków samych ataków:

  1. Błędy w architekturze procesorów pozwalają programom kraść dane, które są aktualnie przetwarzane w komputerze, a konkretnie w pamięci innych uruchomionych programów.
  2. Te dane to na przykład: hasła przechowywane w przeglądarkach, zdjęcia, maile, wiadomości z komunikatorów, dokumenty.
  3. Możliwy jest dostęp do wirtualnej maszyny poprzez fizyczną pamięć komputera hosta z innej wirtualnej maszyny, w której uruchomiony został złośliwy program atakującego.

 

Dlaczego rozwiązanie Hitachi Content Platform (HCP) nie jest podatne na ataki?

[Tomek]:

Jeżeli chciałbyś przeprowadzić atak typu Meltdown lub Spectre (w dowolnym z trzech opisanych dla tych ataków wektorów), musisz mieć możliwość uruchomienia swojego kodu (programu lub skryptu JavaScript) na komputerze swojej „ofiary”. HCP natomiast jest systemem zamkniętym, który nie pozwala ani na instalowanie, ani na uruchamianie jakichkolwiek dodatkowych programów i skryptów na jego serwerach.

Ten sam mechanizm broni nas także przed atakami typu ransomware, które polegają na zaszyfrowaniu danych użytkownika. W tym przypadku również nie uruchomimy złośliwego oprogramowania szyfrującego na serwerach HCP. A dodatkowym zabezpieczeniem dla takiego scenariusza jest wykorzystywana technologia WORM, która gwarantuje niezmienność przechowywanych obiektów. Próba zaszyfrowania (zmiany) obiektu nie powiedzie się.

[Czytelnik]:

Ale zaraz. Przecież HCP to klaster serwerów, z „jakimś” systemem operacyjnym i oprogramowaniem, które dostarcza „jakichś” funkcjonalności.

[Tomek]:

Wszystko się zgadza. Jednak użytkownik (zarówno administrator jak i aplikacja) otrzymuje dostęp do klastra HCP tylko poprzez określony protokół sieciowy w interfejsach GUI i/lub API. Żaden z tych interfejsów nie pozwala na zainstalowanie dodatkowego oprogramowania na serwerach klastra HCP.

[Czytelnik]:

A co w przypadku ewentualnych czynności serwisowych?

[Tomek]:

Inżynier serwisu (i tylko on/ona) ma w trakcie realizowania czynności serwisowych dostęp do systemu operacyjnego serwerów klastra za pomocą zdalnego połączenia SSH. Połączenie to zabezpieczone jest 2048-bitowym kluczem, dostępnym tylko w organizacji serwisowej producenta.

Inaczej mówiąc, dla HCP w wersji appliance nie ma potrzeby aplikowania na serwerach klastra żadnych łatek, które naprawiają opisywany problem.

[Czytelnik]:

W wersji appliance? To jest jeszcze jakaś inna wersja?

[Tomek]:

HCP można również uruchomić w wersji „software only” w postaci wirtualnych maszyn. I tutaj mamy dwa możliwe scenariusze.

  1. W przypadku, gdy na serwerze hostującym wirtualne maszyny, działają tylko te, wewnątrz których jest zainstalowany HCP, wówczas nie ma potrzeby instalowania łatek.
  2. Jeżeli natomiast na serwerze hostującym oprócz maszyn wirtualnych HCP są zainstalowane również inne wirtualne maszyny. I w tych maszynach uruchomione jest oprogramowanie, które w odróżnieniu od HCP, pozwala na instalowanie dodatkowych programów lub skryptów, wówczas należy podjąć działania zabezpieczające i zaaplikować w takiej wirtualnej maszynie odpowiednie łatki (odpowiednie dla wykorzystywanego tam systemu operacyjnego). 
 
Zadanie do rozwiązania.

A na koniec chcę się z Tobą podzielić przemyśleniem z kategorii „ale co to w ogóle dla mnie oznacza”. Zapomnijmy na razie o systemach, które nie są podatne i skupmy się na tych wszystkich, w których istnieje prawdopodobieństwo wystąpienia jednego z dwóch ataków.

Błąd w architekturze procesorów wykryty został przez trzy niezależne zespoły badaczy. Po opublikowaniu bardzo enigmatycznego oświadczenia Intela (chyba pierwszego w tej sprawie), jeden z tych zespołów (zespół Google Projektu Zero) postanowił przerwać milczenie i opublikował szczegóły związane z problemem.

I teraz, czy są wśród Was jacyś matematycy, którzy „ogarniają” rachunek prawdopodobieństwa? Jeżeli tak, to może uda Wam się rozwiązać coś takiego:

 

Zadanie:

Procesory z błędem w architekturze są na rynku od 1995 roku. To oznacza, że czas występowania podatności to 23 lata. Dziura została wykryta przez trzy niezależne zespoły badawcze, które ostatecznie podzieliły się informacją ze światem i nie wykorzystały wykrytych podatności (chyba).

Pytanie 1: 

Jakie jest prawdopodobieństwo, że przez te wszystkie lata błąd nie został wykryty przez inne zespoły?

Pytanie 2: 

Jakie jest prawdopodobieństwo, że po odkryciu podatności zespoły te nie podzieliły się wiadomością ze światem i nie przeprowadziły przynajmniej jednego ataku?

Wskazówka do zadania: 

Pamiętaj, że według badaczy Google nie ma szansy, aby potwierdzić, czy ktoś był ofiarą ataku.

 

Tyle, jeżeli chodzi o domysły i spekulacje. To co wiemy na pewno, to że użytkownicy obiektowej pamięci masowej Hitachi Content Platform dostarczanej w wersji gotowego sprzętowego rozwiązania mogą spać spokojnie. Jest to moim zdaniem kolejny dobry przykład i powód, dlaczego warto, abyś zastanowił się nad tego typu rozwiązaniami w Twojej organizacji.

 

A więcej o obiektowej pamięci masowej oraz niektórych scenariuszach jej wykorzystania przeczytasz również w tym artykule: Obiektowa pamięć masowa zdobywa rynek w Polsce?

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *