20:16
9/3/2015

Na blogu googlowego Projektu Zero właśnie pojawił się opis ciekawego ataku o nazwie “Rowhammer“. Badacze pokazują w nim jak za pomocą wielokrotnie powtarzanych odczytów pewnych obszarów pamięci DRAM można wymusić przeskoczenie bitu w innym obszarze pamięci. Atak jest o tyle groźny, że za jego pomocą złośliwy proces może wpływać na zawartość pamięci innego procesu, do której normalnie z racji separacji nie ma dostępu. Badacze zademonstrowali kod exploita, który dzięki technice Row Hammer uzyskuje prawa roota, pomimo tego, że został odpalony z prawami użytkownika.

Na czym polega atak Rowhammer?

Sam przeskok bitu informacji zapisanej w pamięci RAM, to znany od dawna problem, który opisał w 2003 roku Sudhakar Govindavajhala, a w 2014 roku temat zgłębił Yoongu Kim (por. publikacja naukowa pt. Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors).

W skrócie: wielokrotne uzyskiwanie dostępu do dwóch adresów w pamięci (do której dany proces ma dostęp) powoduje przeskok bitu w trzeciej lokalizacji, która znajduje się w innym rzędzie (ang. “row“) pamięci DRAM na innej stronie (ang. “page“) — innych 4k.

Atak działa, ponieważ współczesne pamięci DRAM stają się mniejsze, przez co komórki pamięci znajdują się coraz bliżej siebie. Taka budowa wprowadza niestabilności układu (komórki oddziałują ze sobą elektrycznie i ładunek z jednej może “wyciec” na sąsiednią). Powtarzanie zapisu niejako większa “wyciek” ładunku, który w końcu może spowodować tzw. “przeskok bitu“, czyli zamianę 01.

2 lata temu opisywaliśmy technikę “bitsquattingu” czyli rejestracji domeny o jeden bit innej niż oryginalna i oczekiwanie aż pod tę domenę zawędruje komputer, którego pamięć RAM doznała błędu (zmiany jednego bita np. na skutek promieniowania kosmicznego).

Od słów do czynów — implementacja ataku Rowhammer

Yoongu i jego koledzy, choć rok temu stwierdzili, że odpowiednie wpływanie na bity w pamięci może prowadzić do przejęcia systemu, to nie zademonstrowali ataku w praktyce. Braki te uzupełnili właśnie badacze Google, którzy do zobrazowania ataku Rowhammer użyli m.in. instrukcji x86 o nazwie CLFLUSH, wymuszającej ominięcie mechanizmu cache — a atak wykonali na systemie Linux. Badacze podejrzewają jednak, że Row Hammera można również wykorzystać na innych architekturach przy pomocy innych instrukcji.

A oto przykładowy exploit:

code1a:
mov (X), %eax // Read from address X
mov (Y), %ebx // Read from address Y
clflush (X) // Flush cache for address X
clflush (Y) // Flush cache for address Y
jmp code1a

Aby całość zadziałała, adresy X i Y muszą być w różnych wierszach tej samej kości pamięci, inaczej odczyty nie będą powodowały tzw. “aktywowania” wiersza (czyli zmian ładunku), a to właśnie wielokrotne aktywowanie umożliwia przeskok bitu. Po opis tego jak odpowiednio dobierać wartości X i Y odsyłamy do oryginalnej publikacji.

Exploity

Badaczom udało się stworzyć 2 działające exploity. Pierwszy ucieka z sandoboksa tzw. “natywnego klienta” (NaCl) na architekturze x86-64 i ma możliwość bezpośredniego odwoływania się do wywołań systemowych systemu operacyjnego. Drugi z exploitów działa jako standardowy proces x86-64 na Linuksie i podnosi uprawnienia zyskując dostęp do całości pamięci fizycznej.

Badacze sugerują też, że Rowhammer może sprawić kłopot w środowiskach zwirtualizowanych.

Tego może się nie dać załatać…

Badacze nie są w stanie oszacować, które konkretnie modele pamięci są podatne na ten atak oraz czy podatność tę w ogóle można “załatać” bez wymiany kości RAM — w końcu przyczyny błędu należy upatrywać w coraz ściślejszym upakowaniu komórek pamięci, co wprowadza pewne konstrukcyjne “niestabilności” układu.

Opublikowane przez siebie wyniki zanonimizowali (nie poznamy nazw podatnych na atak modelów laptopów i prodcucentów pamięci DDR3 DRAM). Dlatego aby sprawdzić czy Wasz laptop jest podatny na ten atak, skorzystajcie z tego skryptu udostępnionego przez badaczy. Jeśli wasza kość jest podatna (pojawiają się błędy) to w zasadzie jedynym pewnym obecnie wyjściem jest zamiana pamięci na ECC lub LPDDR4 — no i oczywiście duża rozwaga w tym, jaki kod (oprogramowanie) uruchamiacie na swoim sprzęcie.

PS. Sprawdzone przez badaczy desktopy były wyposażone w pamięci ECC i żadna z nich nie umożliwiała wykonania ataku Rowhammer. Badacze odkryli też, że niektórzy z producentów BIOS-ów po cichu zwiększyli częstotliwość odświeżania pamięci, co miało utrudnić przeprowadzenie ataków Rowhammer (ale niestety ich nie wyeliminowało).

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

58 komentarzy

Dodaj komentarz
  1. Przedwczoraj było “śmiesznie” jak komputer wyświetlał na ekranie: “Jestem głodny, włóż hamburgera do stacji dyskietek A:”, wczoraj było atakowanie “z nikąd” nie tylko PCtów ale i zespołów przemysłowych (jak np. elektrownie. [BTW, na kij im podłączenie do internetów?]). Dziś mamy przeskakiwanie wolnych zer i jedynek. Pomyślcie, co ciekawego będzie jutro…

    • Jutro, to nie będzie niczego.

    • Jutro nas Skajnety zaatakujom i ekspres do kawy transformuje się w automnomicznego robota, zabójcę. Tak to widzę :) Roman Kluska wiedział co robi.

    • zapamietaj jutra nie bedzie

    • Ale wiecie co? Te stare wirusy były jakieś takie fajniejsze. Albo jakieś zwariowane teksty, albo jakaś równocześnie(!) z programem latająca piłeczka pod DOSem, spadające literki, albo jakaś melodyjka, czy inne rytuały.
      A te dzisiejsze to takie bezpłciowe G, jak sebix z nożem za rogiem.

    • @ewelinka
      Jasne, a błędy pamięci są przez ich zbyt niskie ceny… ;>

  2. Przepisać kernel tak, żeby nie adresował sąsiednich komórek. :)

    • Wątpię czy by pomogło chyb że wprowadzić w to jakiś element losowy, natomiast przynajmniej kilkukrotny spadek wydajności gwarantowany.
      Twój komentarz przypomniał mi jak to kiedyś jakiś doktor na jakimś wykładzie mówił o tym, jak to jeszcze dawniej zmiana adresowania pamięci – a konkretnie ułożenia w niej danych, powodowało spadek czasu obliczeń nawet do kilkudziesięciu razy. Lekarstwo gorsze od choroby.

    • Tak. Nazywało się to “bank interleaving”. Pamięci DRAM logicznie są zorganizowane w 3-wymiarową kostkę: jeden wymiar to rzędy (ROW), drugi wymiar to kolumny (COL), trzeci wymiar to kolejne bity słowa.
      1/ Dostęp do komórki odbywał się tak: pierw do kostki wysyłany był adres rzędu (często była to górna połówka adresu). Kostka go wybierała. Potem wysyłany był adres kolumny (dolna połówka adresu) i na koniec można było pisać/czytać bity.
      2/ Wybór rzędu był dość kosztowny czasowo. Ale jak rząd już był wybrany to stosunkowo tanio można było sobie w nim “jeździć” czytając kolejne słowa (tyko zmiana kolumny) – pamięci obsługujące ten trik to tzw FPM-y (od fast page mode, bo zawartość jednego rzędu nazywana jest stroną – niestety stroną nazywane jest też 138 innych niezwiązanych z tym rzeczy)
      3/ Przejście z jednego rzędu do następnego przy odczycie sekwencyjnym powodowało wstrzymanie procesora na okres ładowania nowej strony.
      4/ Przeplatanie banków sprawiało, że logicznie kolejne rzędy były umieszczone fizycznie w kolejnych kostkach pamięci i po dojechaniu do końca rzędu jednej kostki można było od razu przejść do rzędu na kolejnej, bo się już zdążył “w tle” załadować (trochę jak mechanizm pre-fetch z dysków). Dawało to duże przyspieszenie, bo koszt wybrania rzędu był przykryty przeplotem.
      5/ Oczywiście operacje na bardzo rozrzuconych rzędach wymuszały ciągłe przeładowywanie stron i cały mechanizm szedł w pipę – ale wtedy zaczęto optymalizować struktury danych pod kątem tzw “lokalności”, czyli wszystkie potrzebne dane zebrane razem, żeby nie żonglować rzędami. Ale nie posunąłbym się do “kilkudziesięciokrotnego” wzrostu wydajności.

  3. Elektrownie centralnie dysponowane (jwcd) muszą mieć połączenie aby były zdolne do szybkiego zwiększenia/zmniejszenia ilości generowanej energii koordynowanej przez operatora systemu. Dzieje się tak, ponieważ istnieją elektrownie którymi nie da się sterować np. wiatrowe, wystarczy, że mocniej powieje i trzeba zmniejszyć ilość wytwarzanej energi w elektrowniach konwencjonalnych, inne przypadki to awarie bloków czy sieci (np. aby nie dopuścić do przeciążenia lini to część obciążenia może zostać przesunięta na inne jednostki).
    Ilość energi generowanej do systemu musi być taka sama jak ilość energi zużywanej (na taką skalę nie da się jej magazynować) dlatego praca elektrowni musi być koordynowana.
    Oczywiście intrastruktura operatora systemu jest obiektem strategicznym, dlatego jest zwielokrotniona i rozproszona w nieznanej lokalizacji.

  4. I odstawienie wiatraków załatwi sprawę przeskakującego bitu?

    • miało być po pierwszym komentarzem odnośnie podłączenia elektrowni do internetu.

  5. Kontrolery pamięci AMD – nawet desktopowe, obsługują moduły z ECC i to od wieeeelu lat. Co innego Intel, tam bez Xeona się nie obejdzie.

    • Zależy o jakim chipsecie mowa. Piszę właśnie z kompa Lenovo E31 gdzie siedzi chipset Intel C216 i pamięci ECC.

    • Update: I wcale nie mam Xeona…

    • Standard Ecc jest juz przestarzaly. Az dziw bierze ze nie usprawniaja go. lol

    • Faktycznie widzę jakieś szczątkowe informacje, że polityka Intela się kompletnie kupy nie trzyma – który z tych procesorów masz?

      http://ark.intel.com/search/advanced?s=t&ECCMemory=true

    • A w zasadzie – który z tych masz?

      http://ark.intel.com/search/advanced?s=t&SocketsSupported=FCLGA1155&MarketSegment=DT&ECCMemory=true

    • @Cal: przestarzały bo co? Nie spełnia swojej funkcji podczas lotu na Marsa? Czy po prostu nie masz nic mądrego do napisania i chciałeś tutaj po onetowemu zabłysnąć?

  6. a selinux nie zabezpiecza?

  7. auć:
    error at 0x7fd788829530: got 0xfffffffffffffbff

  8. Gotar: Uprawiasz ‘ta trzecia prawde’ :) Intelowskie chipsety (niektore) obsluguja ECC. Gorzej z notebookami i innym drobnym badziewiem. Dlatego linux i dlatego google :)
    Tableciarze – czas na zmiany?
    ATSD – technike da sie wykorzystac z tego co widac takze zdalnie chociaz trzeba wiedziec conieco o aplikacji (np. serwerze WWW). Bedzie nowy jakze fajny wektor ataku :) Pytanie od ilu lat jest juz to wykorzystywane ze google to podaly publicznie…

    • Tak, podałem nawet linka do procesorów Intela rozumiejących ECC (bo te chipsety, o których mówisz, to po prostu konstrukcje pod xeony). To teraz bądź dzielny i bez wspierania się googlem wymień jakiś zestaw Intela z ECC. Taki że o, pójdziesz do sklepu, powiesz ‘poproszę X’ i będziesz miał (działające!) ECC.

      I gdzie widzisz, że da się to wykorzystać zdalnie, skoro trzeba mieć dostęp do clflush?

  9. Będzie mieć znaczenie jeśli wypróbuję ten skrypt w kompilacji na wirtualnej maszynie?

  10. Czyli mam linuxa i nie jestem bezpieczny??!! Dobra to przerzucam sie na unixa! Hahahahahahaha

    • Na tej liście są exploity na MacOS i Linuxa. Na Windowsa nie widziałem, więc zapraszam ;>.

    • napiszemy i pod windowsa ;-) tak więc zapraszam

  11. Jeśli to działa nawet na defaultowych ustawieniach odświeżania/BIOSu, to jest to bardzo ciekawe. Teoretycznie nawet podczas obliczeń komputer może sam z siebie podmienić dane (prawdopodobieństwo bliskie zeru, ale jednak niezerowe).

  12. Zwirtualizowane… To mnie zastanawia – niemal wszystkie serwery są z pamięciami ECC, czyli winny byłby hypervisor przez to jak zarządza wirtualną pamięcią czy jak?

    • Najtańsze klastry wirtualizacji są budowane z najtańszych podzespołów, gdzie raczej nie ma ECC, procki są z linii desktop (czyli od Atoma do i7), a co gorsza, sprzedawcy rozwiązań “cloud” nie opisują na jakim sprzęcie działają.
      Hypervisor nie ma nic do tego, bo nie ma świadomości błędu, musiałby liczyć “ręcznie” sumy kontrolne bloków pamięci – oczywiście jest to nierealne.

    • Skąd tak dalekoidące wnioski? Środowiska zwirtualizowane są narażone na atak, bo dowolny ktoś sobie może odpalać dowolnie długo dowolny kod. A z ECC będzie to po prostu bezskuteczne. Nie wiem gdzie teraz uczą takiej logiki, że skoro wirtualizacja to serwer, a skoro serwer to ECC – oba wnioski są nieprawdziwe. Owszem, dużo pamięci zwykle oznacza FB-DIMM, a FB-DIMM oznacza zwykle ECC, ale wcale nie jest powiedziane, że wirtualizację robi się tylko na serwerach z dużą ilością pamięci.

      Swoją drogą – bardzo ciekawy atak, wykorzystujący podatność znaną od zarania dziejów (tzn. silent bit rot), poprzez jej wymuszenie w kontrolowany sposób. Stare, dobre hackowanie w stylu wyświetlania obrazu na ramce C64 czy nadajnik radia AM na procesorze.

    • Możliwości są dwie:
      1.Prawdopodobniejsza: testowy serwer z maszyną wirtualną nie miał ECC
      2.Mniej prawdopodobna ale – załóżmy: wirtualna pamięć nie ma ECC ?

      Poza tym, co do ECC to nie wykluczałbym,że trzeba użyć “kilku młotków naraz” by namieszać:
      https://pl.wikipedia.org/wiki/Pami%C4%99%C4%87_ECC

    • Jest bardzo wiele serwerów ze zwykłymi kościami, bez ECC (wystarczy się rozejrzeć po ofertach serwerów dedykowanych – w wielu firmach większość ofert do ok ~100€ miesięcznie nie ma ECC).
      Po drugie, wirtualizację stosuje się także na stacjach roboczych.

    • Yh, doczepiliście się, w sumie słusznie, bo użyłem skrótu myślowego – ja wszystkie serwery jakie pakuję do serwerowni w pracy mam z pamięciami ECC i też to co oferują poważni dostawcy sprzętu też prawie zawsze ma ECC, więc uznałem, że tak jest powszechnie. Faktycznie dinozaur ze mnie, bo nie wziąłem pod uwagę śmiecio-cloud providerów jacy są dzisiaj w modzie.

      Anyway – w tekście było wspomniane że ten atak jest jakoś bardziej nieprzyjemny przy wirtualizacji. Moja wątpliwość była taka: skoro w serwerach wirtualek mam ECC to czy ten atak w jakiś sposób jest w stanie i tak się wykonać ze względu np na dodatkowe warstwy software?

  13. Exploit opatentowany: https://www.google.com/patents/US20140059287

  14. Tak to jest jak się kupuje komputery mało znanych producentów. Źle oprogramowany BIOS może prowadzić do zbyt rzadkiego odświeżania pamięci (z interwałem dłuższym niż rekomendowany przez producenta), co spowoduje takie właśnie kwiatki. Co więcej, w skrajnie wysokich temperaturach częstotliwość odświeżania należy zwiększyć.

  15. nie takie straszne, jak sie wydaje, bo moze i mozna zapisywac gdzie sie chce, ale nie mozna odczytywac, wiec nie wiadomo gdzie zapisac… a przykladowy exploit na linuksa, faktycznie dziala na linuksie… odpalonym w qemu, najpierw wykonuje i analizuje jego zrzuty pamieci, by ustalic, ktory bit zmienic :)

    • No ale lepiej bić na alarm taką właśnie wpisem zamiast zająć się tym, że niedługo dane wszystkich Polaków będzie można znaleźć w internecie wraz z dokładnym adresem zamieszkania.

  16. mielilem to przez dwie godziny na trzech kompach:
    1. laptop dell (Debian 32bit)
    2. desktop skladak (Debian 32bit)
    3. wirtualka w ovh (Slackware 64bit)

    i zadnych bledow.

    • Na laptopie msi 5 latnim, z starymi modułami ddr3, też po godzinie bez błędów.

      Chyba ten atak działa na najnowsze moduły o dużych pojemnościach na jeden układ pamięci.

  17. Ma ktoś może binarkę pod Debiana/ubuntu , byłoby miło.
    Niektórzy nie mają możliwości instalowania SDK.
    Z góry thx.

    • Na twoim miejscu bym się bał odpalać takich binarek

    • Dokładnie. Zapodaj sobie jakiś ODPOWIEDNI LiveCD i z niego kompiluj i testuj.

  18. Spokojnie, to jest tylko bezpieczeństwo komputerowe.
    Świat się nie kończy. NSA i tak nie może się włamać do wszystkich.

  19. Jeszcze jedno uzupelnienie. Chipsety Intela obsluguja ECC od circa epoki nieszczesnego 915
    Co do cache – powinna byc bezpieczna – pamiec statyczna gdzie jest staly przeplyw potencjalny przeplyw pradu a nie przechowywanie w ladunku zgromadzonym w pojemnosci. Jesli cache jest dynamiczne to moze byc tez podatne o ile uklad odswiezania dziala podobnie
    Co do odpornosci na atak zdalny – zalozmy ze zapisujemy w roznych stronach pamieci ram co wymusi flush. Jesli bedziemy pobudzali ta sama kolumne w roznych rzedach to powinnismy uzyskac podobny efekt. Wystarczy teoretycznie znalesc aplikacje ktore mozna zmusic do podobnej dzialalnosci pod nasze komendy. Powiedzmy – jakies mechanizmy wyszukujace informacje w pamieci? W sposob powtarzalny i przy dostatecznie duzym stosunku pobudzen pamieci do komunikacji zewnetrznej? No i nie moze byc tam ‘wspoldzielenia DRAM z video’ czy inna forma odswiezania…

  20. Dla wszystkich obawiających się takiego ataku polecam program MemTest 86 http://www.memtest86.com, który potrafi “młotkować” pamięć i sprawdzać jak bardzo jest podatna.

  21. A nie dałoby się tego rozwiązać software’owo, np. przez wykrywanie próby “młotkowania” przez system i blokowania takiej apki zanim się to uda?

    • Tu problem jest taki, jak z tym sprawdzającym kernelem wyżej.
      Jeśli ktoś chce porównywać obecnie modyfikowaną pamięć z listą niedawnych odwołań i mieć wydajność C64, to owszem, można :)

    • A kto mówi o sprawdzaniu pamięci? Sprawdzać czy exec nie chce wykonywać “młotkerskich” instrukcji na procku i jak próbuje młotkować pamięć wywalać go.

    • Czyli wykrywanie poniższych instrukcji zanim zostaną wykonane:

      mov (X), %eax // Read from address X
      mov (Y), %ebx // Read from address Y
      clflush (X) // Flush cache for address X
      clflush (Y) // Flush cache for address Y

  22. Odpaliłem młotka, po 12 godzinach młot poległ.

  23. Pytanie czy pamięć ECC faktycznie coś na to pomoże. W przypadku 1 bitu ok, ale czy w przypadku wielobitowego przeskoku coś to zmienia?

  24. Chyba chodzi Wam o tunelowanie kwantowe. Spory problem dla minaturyzacji. No ale nic nowego. Ważne jest to, że różni producenci różnie się zabezpieczają przed tym efektem. Stąd nie każdy sprzęt jest tak samo podatny. Nie jest to efekt obowiązkowy, a wszystko zależy od zaawansowania żytej technologii. Tutaj są jakieś przykładowe pomysły: http://en.wikipedia.org/wiki/10_nanometer

  25. PS: Tunelowanie kwantowe to nie jakieś elektryczne przeskoki, jak napisaliście :)

  26. RowHammer nie jest niczym nowym. Podobna technika jest stosowana dla pamięci flash różnych urządzeń autoryzujących, np. kart SIM, czy usb-crpypto-key. w tych układach część pamięci jest zastrzeżona, niedostępna. wielokrotne odczytywanie w wielu przypadkach umożliwia do sięgnięcia do ukrytej części pamięci, normalnie niedostępnej.

    zasadniczo jest to wada sprzętowa, uważam coś takiego za niełatalne. aż dziwne, że takie pamięci przechodzą przez testy jakościowe.

  27. […] O przełomowym ataku na pamięć, pozwalającym odczytywać pamięć innych procesów (bądź ją modyfikować, np. w celu uzyskania wyższych uprawnień) pisaliśmy obszernie kilka miesięcy temu. […]

  28. […] ładunek elektryczny wpłynie na zawartość innej komórki pamięci. Szerzej typ ataku opisał Niebezpiecznik. Jest to spowodowane miniaturyzacją kości pamięci, a co za tym idzie, […]

  29. […] pomoże Ci lepiej zrozumieć z czego wynikają niektóre błędy bezpieczeństwa (por. atak Rowhammer, Bitsquatting, Spectre) i kto wie — może przez kolegów zostaniesz okrzyknięty mistrzem […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: