English

SE-2012-01 Pytania i odpowiedzi

Ostatnia aktualizacja: 05-Mar-2013

Dlaczego sprawdziliście bezpieczeństwo oprogramowania Java dla komputerów osobistych ?
Java znajduje się w zakresie naszego zainteresowania już od prawie dekady. Z sukcesem przełamujemy jej bezpieczeństwo od roku 2002 i jesteśmy ogromnie zafascynowani tą technologią. Pomimo wielu zmian jakie nastąpiły w obszarze aplikacji RIA [1], Java jest nadal obecna na ogromnej liczbie komputerów PC. Według publikowanych danych [2], Java jest zainstalowana na 1.1 miliarda komputerów, a każdego roku odnotowuje się 930 milionów pobrań tego oprogramowania przez użytkowników. Te liczby mówią same za siebie, dlatego też niezwykle trudno jest pomijać Javę w kontekście rozważań nad bezpieczeństwem komputerów osobistych.
Czy trudno jest przełamać bezpieczeństwo Javy ?
Java stanowi jedną z najbardziej ekscytujących i trudnych do przełamania technologii z jaką mieliśmy kiedykolwiek do czynienia. Wbrew powszechnie panującej opinii, nie jest tak łatwo ją przełamać. W celu opracowania stabilnego, niezwiązanego z nadpisaniem pamięci kodu eksploatującego, zwykle kombinacja więcej niż jednego błędu musi zostać użyta aby osiągnąć całkowite przełamanie bezpieczeństwa środowiska Java. To samo w sobie stanowi duże wyzwanie i wymaga głębokiej znajomości implementacji maszyny wirtualnej Java oraz szeregu technik, które mogą być zastosowane do przełamania jej bezpieczeństwa.
Jak to możliwe, że odkryliście aż tyle błędów bezpieczeństwa w najnowszym oprogramowaniu Java 7 ?
Dysponujemy dość dużym doświadczeniem jeśli idzie o przełamywanie bezpieczeństwa Javy. Byliśmy w stanie dostrzec kilka problemów, które zostały najzwyczajniej przeoczone przez Sun Microsystems [3] i/lub Oracle. Zastosowaliśmy również kilka nowych pomysłów w celu naruszenia bezpieczeństwa środowiska Java.
Czy odkryte błędy charakteryzuje coś specyficznego ?
Tak. Odkryte słabości pogwałcają wiele z reguł tworzenia bezpiecznego kodu w języku programowania Java [4]. Większość z nich demonstruje specyficzny problem związany z bezpieczeństwem środowiska Java SE. Problem ten jest wynikiem pewnych wyborów dokonanych na etapie projektu / implementacji oraz w odniesieniu do architektury bezpieczeństwa maszyny wirtualnej języka Java.
Firma Sun Microsystems była świadoma tych problemów już w roku 2005. To w tym czasie odkryliśmy szereg technik ataków i zgłosiliśmy firmie ponad 20+ błędów bezpieczeństwa w Javie. Tym większe jest nasze zaskoczenie, że tak wiele instancji znanego problemu bezpieczeństwa było obecnych w najnowszej wersji oprogramowania Java.
Jakie zagrożenie niosą ze sobą odkryte błędy ?
Najgroźniejsze z odkrytych błędów mogą prowadzić do całkowitego przełamania bezpieczeństwa środowiska Java. Złośliwy aplet lub aplikacja wykorzystująca jedne z nich może działać bez żadnych ograniczeń w kontekście docelowego procesu maszyny wirtualnej Java, takiego jak przeglądarka internetowa. Atakujący może tym samym instalować programy, przeglądać, zmieniać i usuwać dane z uprawnieniami zalogowanego użytkownika.
Zweryfikowaliśmy, że w rezultacie udanego ataku, możliwe jest m.in. tworzenie plików czy też uruchamianie programów w środowisku podatnej platformy Java SE.
W jaki sposób odkryte słabości mogą zostać wyeksploatowane ?
W najbardziej oczywistym scenariuszu ataku, atakujący mógłby przygotować specjalnie spreparowaną stronę WWW zawierającą złośliwą aplikację Java eksploatującą jeden z odkrytych błędów. Po nakłonieniu użytkownika do odwiedzenia takiej strony, np. poprzez namowę do otwarcia określonego odnośnika zawartego w wiadomości email lub komunikatorze, złośliwa aplikacja mogłaby być dostarczona do komputera użytkownika zawierającego podatne oprogramowanie Java.
Możliwy jest też scenariusz, w którym złośliwa aplikacja dostarczona jest na komputer użytkownika za pośrednictwem reklamy wyświetlanej w ramach strony WWW, bądź też innych metod umożliwiających dostarczenie treści stron WWW na system użytkownika.
Czy możliwe jest wykorzystanie błędów bezpieczeństwa w Javie również na serwerach ?
Błędy bezpieczeństwa w Javie mogą być wykorzystane na serwerach jeśli odpowiednio spreparowane dane wejściowe mogą być przekazane do zawierającego błąd interfejsu programistycznego lub komponentu serwera.
Zademonstrowaliśmy taką możliwość w kontekście serwerów Java RMI, takich jak RMI Registry z JDK 7 Update 11 oraz Oracle GlassFish Server 3.1.2.2 (z włączonym menadżerem bezpieczeństwa). Nasz kod ilustrujący demonstruje udany atak na serwisy RMI udostępniane przez wspomniane serwery. Pokazuje on również, że ocena skali zagrożenia stwarzanej przez błędy bezpieczeństwa w Javie firmy Oracle niekoniecznie jest prawidłowa (eksploatujemy błędy, które według firmy Oracle "mogą być wykorzystane wyłącznie poprzez niezaufaną aplikację Java Web Start, bądź aplety Java" [6]).
Wg stanu na dzień 5 Lut 2013, ataki za pośrednictwem protokołu RMI są nadal aktualne i w tym kontekście zdalna eksploatacja błędów bezpieczeństwa w oprogramowaniu Java SE na serwerach powinna być zawsze brana pod uwagę.
Na ile stabilne są wasze programy testujące ?
Z uwagi na to, iż 59 z odkrytych słabości jest błędami w języku Java, nasze programy testujące są całkowicie stabilne i powinny działać bez żadnych problemów na każdej platformie systemowej z zainstalowaną, podatną wersją oprogramowania Oracle Java SE lub IBM Java. Większość z naszych programów wykorzystuje kombinacje jednego i więcej błędów w celu osiągnięcia całkowitego przełamania bezpieczeństwa środowiska Java.
Tylko jeden błąd prowadzi do nieprawidłowego nadpisania pamięci. Opracowiliśmy metodę jego eksploatacji, która umożliwia udane wykonanie kodu w środowiskach za zaimplementowanymi mechanizmami DEP / ASLR, takich jak system operacyjny Windows 7.
Które z błędów zostały poprawione przez aktualizację bezpieczeństwa firmy Oracle dla oprogramowania Java SE z dnia 12 Cze 2012 ?
Są to błędy 10, 13 i 21. Dodatkowo, do kodu zostały wprowadzone zmiany, które uniemożliwiają przeprowadzenie naszego oryginalnego scenariusza eksploatacji błędu numer 26.
Które z błędów zostały poprawione przez aktualizację bezpieczeństwa firmy Oracle dla CVE-2012-4681 z dnia 30 Sie 2012 ?
Są to błędy 11 (jego część nawiązująca do słabości ClassFinder), 16, 17, 20 i 28. Aktualizacja zawiera również poprawkę w kodzie, która uniemożliwia użycie naszego oryginalnego scenariusza eksploatacji prowadzącego do całkowitego przełamania bezpieczeństwa środowiska Java.
Jakie zagrożenie niesie ze sobą błąd 32 odkryty krótko po publikacji poprawki Java SE 7 Update 7 ?
Błąd ten w kombinacji z niektórymi z poprzednio odkrytych słabości pozwala na ponowne całkowite przełamanie bezpieczeństwa środowiska Java 7. Ostatnio, udało nam się również zweryfikować, że błąd ten jest sam w sobie wystarczający do przeprowadzenia ww. ataku.
Jakie wersje oprogramowania Java SE są podatne na błąd 50 zgłoszony firmie Oracle 25 września 2012 ?
Zweryfikowaliśmy, że są to następujące wersje: Java SE 1.4 (build 1.4.2_13-b06), Java SE 5 Update 22 (build 1.5.0_22-b03), Java SE 6 Update 35 (build 1.6.0_35-b10), Java SE 7 Update 7 (build 1.7.0_07-b10) and Java SE 8 (build 1.8.0-ea-b57).
Czy Java SE Critical Patch Update z 16 października 2012 zamyka wszystkie błędy, które zgłosiliście firmie Oracle ?
Nie. Błędy 29 i 50 nie zostały poprawione w ramach tego CPU. Błąd 50 może być wykorzystany do całkowitego przełamania bezpieczeństwa środowiska Java SE 6 Update 37 oraz Java SE 7 Update 9. Frima Oracle poinformowala nas, że oba błędy zostaną poprawiony dopiero w lutym 2013.
Które z błędów zostały poprawione przez aktualizację bezpieczeństwa firmy Oracle dla oprogramowania Java SE z dnia 01 Lut 2013 ?
Według informacji uzyskanej od firmy Oracle, aktualizacja ta poprawia błędy 29, 50, 52 i 53.
Czy aktualizacja bezpieczeństwa firmy Oracle dla CVE-2013-1493 z dnia 04 marca 2013 zamyka jakieś błędy, które zgłosiliście firmie Oracle ?
Nie. Wg stanu na dzień 05 marca 2013, osiem błędów (51, 54-60) pozostaje niepoprawionych. Potwierdziliśmy, że błędy te mogą być wykorzystane do całkowitego przełamania bezpieczeństwa środowiska Java SE 7 Update 17.
Co możecie powiedzieć na temat błędu w oprogramowaniu Apple Quicktime for Java ?
Odkryliśmy jeden błąd (numer 22) w implementacji rozszerzeń języka Java zastosowanych w oprogramowaniu Apple Quicktime. Jego kombinacja z błędem numer 15 zgłoszonym firmie Oracle w dniu 2 Kwi 2012 umożliwia całkowite obejście mechanizmów zabezpieczeń środowiska Java w podatnym systemie.
Błąd w Apple Quicktime for Java ma też swoją historię. Stanowi idealny przykład na zawiłą naturę bezpieczeństwa Javy (to już czwarty raz kiedy sygnalizujemy firmie Apple problem w implementacji poprawki do tego samego błędu bezpieczeństwa).
Jakie są powody włączenia błędów odkrytych w oprogramowaniu IBM Java do projektu SE-2012-01 ?
IBM SDK jest implementacją technologii Java SE firmy IBM. Błędy bezpieczeństwa zidentyfikowane w IBM Java pomagają nam zilustrować określone problemy dot. bezpieczeństwa środowiska Java. Stąd decyzja o uczynieniu ich częścią naszego projektu SE-2012-01 (Błędy bezpieczeństwa w platformie Java SE).
Jak długo pracowaliście nad tym projektem ?
Całość przeprowadzonych badań zajęła nam 3 miesiące pracy.
Czy planujecie opublikować więcej detali technicznych na temat odkrytych słabości bezpieczeństwa ?
Zaprezentowaliśmy rezultaty naszych badań 14 listopada 2012 na konferencji Devoxx Java Community Conference [5] w Antwerpii (Belgia). Udostępniliśmy również raport techniczny i wybrane kody ilustrujące odkryte błędy. Wszystkie opublikowane materiały dostępne są do pobrania tutaj
Większa świadomość pułapek jakie czyhają na programistów w środowisku Java powinna pomóc w ich unikaniu i wykrywaniu, tak podczas prac programistycznych, jak i analizy bezpieczeństwa kodu.
Czy planujecie udostępnić materiały opracowane na potrzeby projektu SE-2012-01 za pośrednictwem waszego płatnego programu wczesnego dostępu do rezultatów badań ?
Nie. Zdecydowaliśmy, że projekt SE-2012-01 będzie projektem badawczym o charakterze Pro Bono. Oznacza to, że wszyscy producenci w których produktach odkryliśmy błędy bezpieczeństwa otrzymują informacje o tych błędach całkowicie za darmo. Dodatkowo, dostarczyliśmy wszystkim producentom kody źródłowe naszych programów testujących celem ilustracji odkrytych słabości bezpieczeństwa.
W oparciu o naszą Polityką Publikacji Informacji, jedynie oryginalni producenci danego oprogramowania / sprzętu otrzymują nasze raporty i informacje o odkrytych słabościach.

Referencje:

  1. [1] Rich Internet application
    http://en.wikipedia.org/wiki/Rich_Internet_application
  2. [2] Learn About Java Technology
    http://www.java.com/en/about/
  3. [3] Sun Microsystems
    http://en.wikipedia.org/wiki/Sun_Microsystems
  4. [4] Secure Coding Guidelines for the Java Programming Language, Version 4.0
    http://www.oracle.com/technetwork/java/seccodeguide-139067.html
  5. [5] Devoxx conference, "Security vulnerabilities in Java SE" talk
    http://www.devoxx.com/display/DV12/Security+vulnerabilities+in+Java+SE
  6. [6] Oracle Java SE Critical Patch Update Advisory - February 2013
    http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html

Copyright 2008-2018 Security Explorations. All Rights Reserved.