24.06.2015 | 19:00

Adam Haertle

Jak Polak zabezpieczenia Adobe Readera i Windows jednym błędem pokonał

Nasz rodak Mateusz j00ru Jurczyk odkrył błąd, dzięki któremu można było otwierając plik PDF ominąć zaawansowane mechanizmy bezpieczeństwa wszystkich wersji Adobe Readera i systemu Windows oraz wykonać dowolne polecenie.

Automatyczne wykonanie kodu na poziomie systemu operacyjnego po otwarciu jednego dokumentu z reguły wymaga połączenia kilku błędów – trzeba zmusić czytnik plików do wykonania nieautoryzowanego polecenia, uciec z piaskownicy, w której pracuje a do tego ominąć zabezpieczenia systemu operacyjnego, których zadaniem jest maksymalnie utrudnić pracę atakującego. Nie pamiętamy, by kiedykolwiek wcześniej udało się to wszystko osiągnąć za pomocą jednego, jedynego błędu. Nawet jeśli jest jakiś precedens, to jest to bardzo rzadki przypadek zasługujący na uwagę.

Łowca błędów

j00ru stałym czytelnikom z3s nie trzeba przedstawiać – współzałożyciel Dragon Sectordwukrotny laureat Pwnie i członek zespołu Google Project Zero to jeden z naszych najlepszych branżowych towarów eksportowych. Gdy kolejny wpis na jego blogu zawiera słowa „spędziłem kilka tygodni nad inżynierią wsteczną biblioteki” to gwarantowanym elementem wpisu będzie długa lista CVE stanowiących plon jego pracy.

Tym razem j00ru postanowił przyjrzeć się najwyraźniej zbyt rzadko analizowanemu modułowi Adobe Type Manager Font Driver (ATMFD.DLL) odpowiadającemu za obsługę czcionek Type 1 oraz OpenType w jądrze Windows od wersji NT 4.0 po 8.1. Swoją pracę skupił na funkcjach zajmujących się przetwarzaniem CharStrings, czyli binarnych programów PostScript. Już na początku zauważył, że kod jest raczej marnej jakości oraz zawiera mnóstwo funkcji, które często nie są od dawna w ogóle używane (standardy związane z tym obszarem były rozwijane głównie w latach 80. i 90). Już same te obserwacje oznaczają, że jest to ciekawe pole do eksploracji – dodatkowym bonusem jest fakt, że prawie identyczne funkcje istnieją nie tylko w jądrze Windows, ale także w Adobe Readerze i kilku innych środowiskach.

Wiele tygodni analizy kodu zaowocowało zgłoszeniem producentom piętnastu błędów, od mniej istotnych po nieograniczoną możliwość wykonania dowolnego kodu w środowisku Adobe Readera oraz Windows (CVE-2015-0093 załatany w Windowsie w marcu oraz CVE-2015-3052 załatany w Adobe Readerze w maju). Niech nie zwiodą Was osobne CVE – błąd co do zasady jest identyczny.

Wyniki pracy j00ru

Wyniki pracy j00ru

Jeden błąd a tyle radości

Nie będziemy udawać, że potrafimy przybliżyć szczegóły techniczne odkrycia błędu oraz sposobu jego wykorzystania. Zainteresowanych szczegółami odsyłamy do pliku z prezentacją Mateusza (tak, link prowadzi do PDFa, a właśnie o błędach w przetwarzaniu tych plików traktuje prezentacja). Błąd co do zasady pozwala na zaawansowane manipulacje zawartością stosu, dzięki którym odpowiednio spreparowany plik PDF jest w stanie przejąć kontrolę nad Adobe Readerem oraz wykorzystując ten sam błąd, lecz zaimplementowany w jądrze Windows, uciec z piaskownicy Adobe Readera i po drodze ominąć wszystkie zabezpieczenia Windowsa. Czym innym jest jednak odkryć błąd, a czym innym napisać kod eksploita, który udowodni, że błąd faktycznie istnieje.

W świecie autorów eksploitów opisywany rodzaj ataku jest czymś w rodzaju Świętego Graala. Dzięki specyficznej lokalizacji i charakterowi błędu pozwala on atakującemu na ominięcie skomplikowanych zabezpieczeń, mających za zadanie uniemożliwienie wykonania obcego kodu. Mechanizmy takie jak ASLR, DEP czy SMEP w które wyposażony jest Windows nie są w stanie powstrzymać kodu eksploita, ponieważ ten omija wszystkie obszary objęte ochroną. Atak zaprojektowany przez Mateusza nie wymaga zgadywania adresów i strzelania na ślepo – dzięki temu jego przebieg jest w pełni przewidywalny i daje w zasadzie gwarantowany skutek. Oczywiście tego rodzaju osiągnięcia nie przychodzą łatwo – jeśli odważycie się pobrać prezentację, to znajdziecie tam prawie 200 slajdów, na których Mateusz opisuje swoje boje z eksploitem. Ich efektem końcowym jest plik PDF, którego otwarcie w najnowszym (w momencie odkrycia błędu) Adobe Readerze i Windows 8.1 powoduje eleganckie uruchomienie legendarnego narzędzia hakerskiego calc.exe – jak na filmie poniżej.

Będzie nagroda?

Opisywany powyżej atak w wariancie wykorzystującym tylko jeden błąd działa na wszystkich 32-bitowych wersjach Windows. Oczywiście autor nie byłby sobą, gdyby nie udowodnił, że także wersje 64-bitowe są podatne – chociaż tutaj musiał iść na małe ustępstwo i wykorzystać inny błąd odkryty przy okazji. Jako że Mateusz już dwukrotnie zdobywał Pwnie Award, pomyśleliśmy, że skoro zasady nominacji do tegorocznej edycji mówią o błędach opublikowanych do 30 czerwca 2015, to ten jak najbardziej się kwalifikuje i na wszelki wypadek przesłaliśmy organizatorom konkursu nominację w kategorii Pwnie for Best Client-Side Bug. Jeśli kojarzycie jeszcze jakieś osiągnięcie naszych rodaków warte nagrodzenia i opublikowane w ciągu ostatnich 12 miesięcy, to podeślijcie nam – lub zgłoście sami w odpowiedniej kategorii. Nominacje są zbierane do 30 czerwca.

Powrót

Komentarze

  • 2015.06.24 19:24 Albert

    Nic, tylko pogratulować i życzyć stosownej nagrody :)

    Odpowiedz
  • 2015.06.24 19:53 marcin

    Jeśli się nie mylę błędy dotyczą nie tylko Adobe Readera, ale w zasadzie wszystkich programów na Windowsie. Czyli pewnie mógłby równie dobrze napisać exploit na Chrome, ale było by to trochę niepolityczne :)

    Odpowiedz
    • 2015.06.24 20:42 Gynvael Coldwind

      Firefox i Chrome korzystają z font sanitizera, który by odrzucił spreparowanego fonta w tym wypadku.

      Odpowiedz
      • 2015.06.25 08:30 Ninja

        I nie da się tego ominąć, Gyn? ;)

        Odpowiedz
  • 2015.06.24 20:34 Gyeroy

    Dlatego polecam linuxa :)

    Odpowiedz
    • 2015.06.24 20:43 Gynvael Coldwind

      Niestety! j00ru i tam już był ;o http://seclists.org/oss-sec/2012/q1/581
      Boje się o swoją lodówkę…

      Odpowiedz
      • 2015.06.24 20:51 Adam

        To już chyba tylko BlackBerry zostaje

        Odpowiedz
        • 2015.06.24 21:06 Krystian

          No nie wiem… nowe blackberry będą na Androidzie ;)

          Odpowiedz
      • 2015.06.25 14:03 Imię

        Moment, moment. Ale błędy, które wskazujesz są w bibliotece freetype. ATFMD.DLL działa – o ile dobrze rozumiem – w jądrze windows. To trochę inna kategoria babola.

        Odpowiedz
        • 2015.06.25 20:58 Gynvael Coldwind

          Zgoda :)

          Odpowiedz
      • 2015.06.26 11:39 kez87

        A tam,nowych exploitów na systemd jeszcze nie znalazł, więc tak strasznie pod nowymi red-hatopodobnymi nie jest – prawda ?

        Odpowiedz
  • 2015.06.25 00:32 brthn

    Pff, linux ma taki sam burdel w źródłach jak Windows. Nie da się uniknąć błędów przy milionach linii kodu. W tym momencie zwolennicy microkerneli śmieją się zza swoich nadal nieużywalnych os’ów…

    Odpowiedz
  • 2015.06.25 17:27 Mike Wazowski

    a nie prosciej zrezygnowac z adobe readera? :)

    Odpowiedz
    • 2015.06.25 20:24 nikt

      Nie każdego PDFa inne programy otworzą, nawet ostanio mi się trafił taki z „Adobe Presenter” który w innych czytnikach (testowałem na PDF-XChange Viewer i Czytniku z Windowsa 8) daje pustą stronę.

      Odpowiedz
  • 2015.07.01 21:33 Flyn

    nikt,
    Piszesz zapewne o czymś, co ma również miejsce w Adobe, tyle, że tam oprócz pustej strony dostajesz komunikat „unefficient data for an image”. Foxit sobie radzi z takimi przypadkami.

    Odpowiedz

Zostaw odpowiedź do Flyn

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Jak Polak zabezpieczenia Adobe Readera i Windows jednym błędem pokonał

Komentarze