Czasem zdarzają się błędy inne niż wszystkie. Na początku wszyscy kiwają głowami i mówią „no ciekawy błąd, ale wykorzystać to się go nijak nie da”. A potem przychodzi ktoś, kto nie wie, że się nie da i pisze działającego eksploita.
To, że odczytując fragmenty pamięci da się magicznie zmienić zawartość innych jej obszarów, jesteśmy w stanie jeszcze jakoś od biedy zrozumieć. Ale to, że komuś udało się to wykorzystać, by w powtarzalny i solidny sposób uzyskać ucieczkę ze środowiska wirtualnego lub podniesienie uprawnień w systemie linuksowym – to już nam się ledwo w głowie mieści.
My tu czytamy, a tam się zmienia
Wszystko zaczęło się w połowie zeszłego roku od ciekawej pracy opisującej zadziwiający proces zmiany zawartości bitów układów pamięci DRAM bez ich „dotykania”. Badaczom udało się spowodować zmianę z 0 na 1 (lub odwrotną) przez powtarzane wielokrotnie odczytywanie przylegających fizycznie komórek pamięci. Zjawisko to spowodowane jest ogromną gęstością upakowania komórek pamięci która powoduje, że operacje na jednych komórkach mogą – poprzez ładunki elektryczne – wpływać na stan innych komórek. Nie będziemy udawać, ze rozumiemy, jak dokładnie przebiega ten proces – szczegóły znajdziecie w pracy naukowej temu poświęconej.
Początkowo badacze zajmujący się kwestiami bezpieczeństwa nie byli przekonani, czy da się ten błąd wykorzystać do ataków prowadzonych w świecie rzeczywistym. Na szczęście jednak po świecie chodzą ludzie, dla których nie ma rzeczy niemożliwych, są tylko takie, których jeszcze nie spróbowali. Panowie Mark Seaborn i Thomas Dullien zajęli się tematem i owocem ich prac jest publikacja na blogu Google Project Zero opisująca, jak można odkryte błędy wykorzystać do niecnych celów.
Losowe zmiany bitów i podnoszenie uprawnień
Badacze musieli poradzić sobie z wieloma wyzwaniami. Ich praca wymagała bardzo dobrego zrozumienia zasad alokacji pamięci oraz jej fizycznych struktur w układzie scalonym. Dzięki kilku dobrym pomysłom i wielu eksperymentom udało im się wypracować metodę takiego prowadzenia zmasowanego odczytu poszczególnych bloków pamięci, by do losowych zmian bitów zachodziło w ściśle określonych obszarach, które leżały w centrum ich zainteresowania. Ponownie nie będziemy udawać, że rozumiemy ten proces – wiemy jednak, że się im udało.
W swoich eksperymentach badacze udowodnili dwa możliwe scenariusze ataku. Pierwszy z nich polega na ucieczce z maszyny wirtualnej dzięki uzyskaniu możliwości modyfikacji zawartości pamięci cudzych procesów, zaś drugi to podniesienie uprawnień w systemie dzięki możliwości kontrolowania zapisu w dowolnym obszarze pamięci. Opublikowane zostały dwa eksploity – jeden ucieka z piaskownicy Native Client, zaś drugi podnosi uprawnienia w systemie linuksowym.
Dziękujemy za pamięć
Czy mój komputer jest podatny
To bardzo dobre pytanie. Badacze testowali 29 różnych laptopów – nie daje to podstaw do wnioskowania na temat całej populacji, ale daje przybliżony obraz skali zjawiska. W 14 przypadkach zaobserwowano zmianę stanu bitów, w 15 laptop był odporny. Badacze nie wymienili konkretnych marek sprzętu ani producentów układów pamięci, jednak analizując ich symbole można dojść do wniosku, ze nie ma żadnego „bezpiecznego producenta”. Spośród 5 różnych dostawców układów pamięci jeden okazał się być w przeprowadzonych testach odporny na atak.
Co ważne, wszystkie testy przeprowadzono na sprzęcie, którego kości pamięci nie posiadały wbudowanej korekty błędów ECC. Nie oznacza to, że pamięci serwerowe z korektą błędów są odporne na atak – według badaczy w ich przypadku atak choć trudniejszy do przeprowadzenia, to dalej jest możliwy.
Czy mój komputer jest podatny – by odpowiedzieć na to pytanie wystarczy uruchomić odpowiednie narzędzie testujące. Na szczęście istnieją już mechanizmy, których zadaniem jest wyeliminowanie tego błędu. Nowe układy pamięci mają korygować takie pomyłki, prawdopodobnie mechanizm ten wdrożył już jeden z producentów układów obecnie sprzedawanych na rynku. Dodatkowo niektóre możliwości przeprowadzenia ataku można wyeliminować przez aktualizację BIOSu.
Podsumowanie
Trzeba przyznać, że opisywany powyżej błąd i jego metoda wykorzystania to jedne z najciekawszych odkryć ostatnich, bogatych w zdarzenia miesięcy. Jak sięgamy pamięcią, podobny błąd poprzedni raz został zidentyfikowany w roku 2003, gdzie ucieczkę z wirtualnej maszyny mógł zapewnić jeden błędnie odczytany bit zmieniony np. przez promieniowanie kosmiczne. Błędy na styku sprzętu i oprogramowania to rzadko badana dziedzina – tym większe wyrazy podziwu należą się autorom odkryć opisywanych powyżej.
Dalsza lektura:
Komentarze
// Note that we use gettimeofday() (with microsecond resolution)
// rather than clock_gettime() (with nanosecond resolution) so
// that this works on Mac OS X, because OS X doesn’t provide
// clock_gettime() and we don’t really need nanosecond resolution.
czy mozna liczyc na jakas analize kodu krok po kroku?
Kolego to:
1.Asembler
2.Architektura pamięci
Rzecz jest bardzo niskopoziomowa,sam też nie bardzo aż takie numery rozumiem – szczerze mówiąc,to wydawało mi się,że pamięci są trochę lepiej zrobione a procesy systemowe zajmują trochę lepiej rozłożone obszary pamięci, pomimo zastosowania stronicowania (jakby ktoś nie kojarzył tego pojęcia z architektury komputerów: https://pl.wikipedia.org/wiki/Stronicowanie_pami%C4%99ci )
Rzut oka na tekst wskazuje,że problem wynika m.in. stąd,że
1.kernele nie wykluczają pewnych operacji niskiego poziomu na pamięci dokonywanych przez użytkownika,jak np. nieszczęsne CLFLUSH ani nie nadzorują tego dostatecznie (no co: nawet sam Linus może mieć problem z tymi całymi architekturami procków i ich komendami – a to,że kernela nie prowadzi sam nic nie poprawia)
2.Można sobie (jak ? nie doczytałem) mapować pamięć należącą do systemu/superużytkownika/innych użytkowników.
Całość wygląda ciekawie,ale wyjaśnienie tego naprawdę krok po kroku nie wymagaj od Adama ani od większości ludzi (włącznie ze mną) którzy nie siedzą tak w asemblerze i przy produkcji pamięci. Same podręczniki dla programistów od Intela to tomiska po kilkaset stron,tomów też co najmniej jest kilka (więc co z tego,że dostępne od ręki na stronie intela ?),niby obecnie same procki są bliżej RISC a jakoś tego nie widać… Instrukcji w ch… i co one znaczą,to wie mało osób.
A że hardware jest kiepsko chronionym wektorem ataku to wiadomo od dość dawna. Jak open source w hardware jest na etapie arduino, kodów na FPGA albo prostych procków i prymitywnych GPU na architekturze wishbone (gdzieś przepasłem swoje hasło na opencores a nie chce mi się wyrabiać nowego logina) z których raczej trudno byłoby postawić samodzielny komputer to czemu się tu dziwić ? Dla zdecydowanej większości „jak zrobić komputer” nawet sprzed 20 lat to czarna magia.
Samo zrozumienie jak coś było zapisywane na dysku talerzowym to „wąska specjalistyczna wiedza”.Nie będę udawał – póki co w tej niedoinformowanej większości jestem i raczej długo będę.
A co do pamięci ECC to korygują tylko określoną ilość błędów,a z tego opisu to wynika,że te exploity „śmiecą” w pobliskich (najlepiej ściśle określonych i bliskich) sektorach pamięci – więc pewnie więcej „śmieci” i jest szansa,że i pamięci ECC mogą zostać pokonane. Bardziej mnie zastanawia,czy ta technika w realniejszym zastosowaniu nie może przy okazji spowodować również innego rodzaju awarii niż przejęcie uprawnień – w większej liczbie przypadków niż sama eskalacja uprawnień.
wow, dzieki za wyczerpujaca odpowiedz :)
http://www.exploit-db.com/author/?a=7725 – poce ?!?
Ogólnie rzecz biorąc jako wybitny ekspert mogę podać przyczyny tego stanu rzeczy a wy oczywiście chcecie posłuchać :)
No więc wszystko przez to że nie mieli FireEye – a
Jakoś tydzień temu pomyślałem że wole nie za gęsto upakowane kości RAM wsadzić do laptopa bo są mniej upakowane = bardziej odporne na ataki typu taka hardware’owa zmiana zawartości pamięci.
Czy był taki artykuł ostatnio?
Czy ja dobrze zrozumiałem, że to jest możliwe nawet na domyślnej konfiguracji, bez gmerania w czasach odświeżania i zakątkach BIOSu/firmware?
Z tego by wynikało, że każdy taki komputer dokonujący obliczeń może raz na X czasu w szczególnych przypadkach sam z siebie podmienić dowolny bit w dowolnym bajcie… Prawdopodobieństwo prawie zerowe, ale jednak większe od zera… ;/
DOBRZE zrozumiałeś.Niestety na to właśnie wygląda – przy intensywnych obliczeniach oczywiście. Zresztą takich błędów jest więcej.GPU i procki np. różnie zaokrąglają zmiennoprzecinkowe liczby ujemne (stąd mają małą ale potencjalnie nawarstwiającą się różnicę w liczbach zmiennoprzecinkowych). Może w terminie: „jutro” coś o takich błędach nawet sam napiszę,to dobry temat.Się zobaczy.
Tak i nie.
Tak – jeśli się ma RAM z wadliwej serii to rowhammer działa bez zmian w BIOS/etc.
Nie – w normalnej pracy raczej nie powinno się to zdarzać, z uwagi na to, że CPU stara się jak najrzadziej odwoływać do RAMu i korzysta raczej za cache’u. Jak czegoś nie ma w cache, to jest to ściągane z RAM do cache i wtedy CPU i tak operuje na cache. No i w normalnej pracy raczej nie ma odpowiednich access patternów które by powodowały częste flushowwanie cache.
Ale… promieniowanie kosmiczne to inna sprawa – przez nie może być trochę random bit-flipów. W http://gynvael.coldwind.pl/?id=403 podlinkowałem trochę różnych materiałów na ten temat.
Gynvael ty tu jesteś specjalistą,ale pytanie brzmi : co masz na myśli pod pojęciem „normalna praca” ?
A) Zwykły użytkownik i jego pecet
B) Serwer czy symulacja – zwykłe
C) Bardzo obciążony (ponad 97%) a nawet przeciążony sprzęt robiący za serwer albo klepiący symulację naukową / przemysłową – na tyle skomplikowane,że cache jest do tego chronicznie za mały, ramu też za mało itd (bo menadżer skąpy był np.)
Jeśli się kompletnie pomyliłem twoim zdaniem przy odpowiedzi do adama – wal z tym śmiało :)
Ja tam szczerze mam obawy do C czy system / aplikacja to obsługująca bez ECC po takiej pracy nie ma szans zacząć lekko niestabilnie się zachowywać z powodu przeskoku prądu. Oczywiście wiem: prawdopodobieństwo,że trafi na coś poważnego cały czas małe. Ale czy to byłby scenariusz godny choć przemyślenia czy raczej kosza ?
Czytaj: Jakie warunki mogłybyby doprowadzić do odtworzenia tego ataku w formie przypadkowej usterki ?
Mam linuksa, czy jestem….
Nie k…. nie jesteś bezpieczny.
Za to pod windowsem nie będziesz bezpieczny dłużej i z większej liczby powodów.
A exploita pod Windowsa nie podano… czyżby najbezpieczniejszy system? :> :D
Cierpliwości, IDA Pro nie rośnie na drzewach, tak potencjalnie dobre exploity też. Najpierw chętni muszą zrobić windowsową wersję,potem dokonać ataków a dopiero na samym końcu jak wycieknie albo ataków będzie za dużo ktoś zrobi tą łatę i wyjaśni jak to zaadaptowano do windowsa ;) Różnica pomiędzy zamkniętym a otwartym kodem to również różnic w inspekcji kodu i wydawaniu łat. Pewnie za kilka lat o takich atakach na windows przeczytamy.
Każda „cyfrowa” elektronika jest tak na prawdę w głębi całkowicie anaglogowa, a ponieważ co raz bardziej schodzimy z rozmiarami, to docieramy do punktu, w którym zaczynają mieć miejsce zjawiska opisywane przez fizykę kwantową. Zwykłe losowe termiczne ruchy elektronów mogą same z siebie spowodować że gdzieś „0” przeskoczy na „1”. Jest to niezwykle mało prawdopodobne i elektronika jest projektowana tak, by te błędy wykrywać i naprawiać, ale w momencie zmasowanego ataku zaprojektowanego w odpowiedni sposób po prostu się poddaje.
Trochę mnie ciekawi, jak można uciec z maszyny wirtualnej, w końcu nie ma ona dostępu do pamięci jądra, więc nawet mogąc modyfikować różne bity poza vm, nie wiemy, co tak naprawdę modyfikujemy, a jak do tego dojdzie jeszcze ASLR…
i mamy rozwiazanie. przykladowy exploit na linuksa, faktycznie dziala na linuksie… odpalonym w qemu, najpierw wykonuje i analizuje jego zrzuty pamieci, by ustalic, ktory bit zmienic :)
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.
Prawidłowo skonfigurowany kontroler pamięci ECC w przypadku pojedynczego błędu może go poprawić a jeśli błąd jest z natury niekorygowalnych bo dotyczy większej ilości bitów to zgłaszane do procka powinno być przerwanie niemaskowalne i minimum to „blue screen” lub inny efekt kończący przetwarzanie. Może jest tak, choć nie znam na tyle architektury Intela/AMD/ innych że możliwe by było wyłączenie wadliwego bloku pamięci z dalszej pracy ale to powinno odbywać się 'w sprzęcie’ a nie na poziomie kernela.
przykład opisu:
http://www.ti.com/lit/ug/spruhn7b/spruhn7b.pdf (ECC strona. 30)
JESD79-3C standard
Poczekajmy jak ktoś pobawi się 'wytanionym hardware-owo’ tabletem czy smartfonem
gdzie energii do refreshu DRAMu jak na lekarstwo a cała pamięć to jedna kostka ;)