AnC kończy z ASLR: 22 rodziny procesorów bezbronne wobec ataku w JavaScripcie

AnC kończy z ASLR: 22 rodziny procesorów bezbronne wobec ataku w JavaScripcie

AnC kończy z ASLR: 22 rodziny procesorów bezbronne wobec ataku w JavaScripcie
16.02.2017 11:50, aktualizacja: 16.02.2017 12:16

ASLR⊕Cache (AnC) to atak opracowany przez informatyków z VrijeUniversiteit w Amsterdamie, który napisano w JavaScripcie i któryuruchomimy w każdej przeglądarce. Wymierzony w jednostkizarządzania pamięcią (MMU) mikroprocesorów, z łatwością łamiezabezpieczenia randomizacji przestrzeni adresowej (ASLR). Wyjątkowymten atak czyni jednak coś innego – zagrożone są co najmniej 22różne mikroarchitektury, zarówno x86-64 jak i ARM.

Szczegóły opisanena łamach uniwersyteckiego bloga VUsec dają do myślenia. ObecnieASLR jest podstawową linią obrony przed zdalnymi atakami. Losoworozmieszczając kod i dane aplikacji w przestrzeni adresowej,poważnie utrudniają napastnikom manipulacje, mogące naruszyćbezpieczeństwo oprogramowania. Znane słabości tej technikiograniczone były do szczególnych wypadków, w szczególności dolokalnego uruchamiania natywnego kodu, z dostępem do kernelasystemu. Przeglądarki, w których uruchomić można przecieżjedynie JavaScript, uważano za skutecznie zabezpieczone przez ASLR.

Zespół holenderskich badaczy już rok temu pokazał jednak, żekorzystając z mechanizmu deduplikacji pamięci można obejśćzabezpieczenia ASLR w przeglądarce Microsoft Edge. Wynik ten zostałprzedstawiony ze szczegółami w artykulept. Dedup Est Machina: Memory Deduplication as an AdvancedExploitation Vector. Reakcja Microsoftu była bardzo szybka –po prostu wyłączył deduplikację.

Fast version of AnC

Kilkanaście sekund i atak AnR namierza położenie aplikacji w pamięci
Kilkanaście sekund i atak AnR namierza położenie aplikacji w pamięci

Teraz jednak nie bardzo jest co wyłączać, to nie czasy Amigi,gdzie systemy radziły sobie bez jednostek zarządzania pamięcią.Wystarczy 90 sekund, by za pomocą AnC napastnik mógł odczytaćobszary pamięci z aplikacją i jej danymi – a następnie uruchomiłwymierzone w nią exploity.

Jak wyjaśniają badacze, to atak typu side-channel (a więc taki,który pozyskuje informacje z fizycznej implementacji, a nie zteoretycznej słabości algorytmu). Mierząc czas operacji w buforzemikroprocesorów (EVICT+TIME), udało się ustalić, do którychlokalizacji MMU uzyskuje dostęp podczas przeglądania stron pamięci.AnC na początku oczyszcza część pamięci cache najwyższegopoziomu, a następnie mierzy czas w jakim MMU przegląda tabelęstron pamięci podczas uzyskiwania tam dostępu. Później pozostajewyszukać, które linie cache należą do którego poziomu tabelistron i znaleźć offset wpisu w takiej linii cache.

To nie jest tylko akademicka ciekawostka, nawet najlepszeimplementacje ASLR z wysoką entropią nie są tu bezpieczne, a conajważniejsze, taki atak udało się zakodować w JavaScripcie.Działa on w przeglądarkach mimo tego, że ostatnio producenciprzeglądarek celowo zepsuli precyzyjny licznik performance.now(),aby uniemożliwić wcześniej znane ataki na cache. Holendrom udałosię stworzyć dwa własne liczniki – i to one umożliwiająprecyzyjny pomiar, pozwalający odróżnić bezpośredni dostęp dopamięci od dostępu przez cache.

AnC został przetestowany na 22 różnych mikroarchitekturachprocesorowych, w tym Skylake, Haswell, Piledriver, K10, Cortex A53czy Cortex A15. W praktyce, ofiarą padły wszystkie testowaneprocesory takich producentów jak Intel, AMD, Samsung czy Nvidia. Jeśli chcecie sprawdzić, jak to działa na Waszych maszynach, kod źródłowy znajdziecie na GitHubie.

Jak się zabezpieczyć?

Póki co nie możemy się zabezpieczyć. Atak wykorzystujefundamentalne własności budowy mikroprocesorów. Co najwyżej możnazablokować uruchamianie nieautoryzowanego JavaScriptu wprzeglądarce, np. za pomocą rozszerzenia NoScript. Kompleksowezabezpieczenie przynieść mogą jedynie prace producentów sprzętui oprogramowania, koordynowane przez holenderskich badaczy.

Obecnie prace nad uodpornieniem procesorów Intela prowadzone sąw ramach CVE-2017-5925, procesory AMD otrzymały CVE-2017-5926, aprocesory ARM – CVE-2017-5927. Póki co wygląda na to, żepierwsze uodporniło się Apple, utwardzając silnik WebKit w wersji10.2.1 iOS-a.

Programy

Zobacz więcej
Źródło artykułu:www.dobreprogramy.pl
Oceń jakość naszego artykułuTwoja opinia pozwala nam tworzyć lepsze treści.
Wybrane dla Ciebie
Komentarze (23)