Log4j, czyli dziurawy świat open source bez budżetu
Od mniej więcej dwóch dni internet płonie, a administratorzy są wzywani na nadgodziny lub weekend by łatać krytyczną lukę w powszechnie używanej w aplikacjach Java bibliotece Log4j. Służy ona za interfejs do raportowania zdarzeń do systemowych lub aplikacyjnych logów, bez konieczności samodzielnego dbania o dostęp do nich. Luka umożliwia zdalne wykonanie kodu na prawach aplikacji.
Jak wykorzystać niniejszą podatność? Trzeba wysłać do aplikacji złośliwe żądanie, które zostanie zalogowane przez Log4j w nieprzetworzonej postaci. Przejście żądania "przez" bibliotekę poskutkuje, zamiast zapisania go do logów, wykonaniem kodu. A więc jeżeli aplikacja stosuje Log4j (w wersji 2.x), jeszcze nie musi to oznaczać że jest podatna. Ale jeżeli istnieje taka część żądania, która ląduje w logach niepołamana, niezaciemniona i "niewy-escape-owana", aplikacja jest zagrożona. Takich aplikacji jest... mnóstwo. Są dosłownie wszędzie. Wszak "trzy miliardy urządzeń stosują Javę", jak zwykł mawiać Oracle.
Załatane, ale gdzie?
Jest już, oczywiście, łatka, ale wiele aplikacji rozprowadzanych jest razem z runtimem. To doskonałe podejście ułatwiające rozwój oprogramowania, uodparniające przy okazji na problemy z zależnościami. Ale w przypadku zastosowań lub kalendarzy wydawniczych, gdzie aktualizacje przeprowadzane są rzadko, będzie to oznaczać dziurawą bibliotekę obecną nieprzyzwoicie długo.
A to jest z tych problemów, który naprawdę szybko powinien zniknąć. Problem jest na tyle poważny, że jest o nim głośno w niespodziewanych miejscach: Microsoft aktualizuje Minecrafta i wydaje artykuł na temat problemu. Kaspersky opisuje poziom ryzyka. Docker silnie zaleca administratorom przegląd swoich kontenerów pod kątem Log4j. VmWare wydaje tuziny aktualizacji. Okta naprawia swoje narzędzia zapewniające bezpieczne... logowanie (no pun intended).
Niewdzięczne zajęcie
Podatność otrzymała identyfikator CVE-2021-44228 i pieszczotliwą nazwę "Log4Shell" (nie mylić z Left 4 Dead). Nieoficjalna lista podatnego oprogramowania ma 18 stron i rośnie. Weekend w infosec jest pracowity, także dla autora niniejszej notatki. Powstaje zatem pytanie - jak to jest możliwe? Jakim cudem problem z jedną biblioteką wywołuje pożar na taką skalę?
Odpowiedź jest prosta: to powtórka z roku 2014 i podatności Heartbleed. Olbrzymia dziura w OpenSSL istniała niezauważona przez długi czas ze względu na to, że projekt był chronicznie niedofinansowany. Etatowo, w pełnym tego słowa znaczeniu, nie pracował nad nim nikt. Problem był na tyle duży, że OpenBSD dokonało nawet forka: LibreSSL. A na OpenSSL stoi niemal cały internet.
Jest kilka takich programów. OpenSSL, cURL i Perl to tylko kilka pierwszych przykładów z brzegu. W tym tygodniu okazało się, że do zbioru zapuszczonych programów należy także Log4j. Jego opiekunem jest Fundacja Apache. Biblioteka nie miała jednak pełnoetatowych deweloperów. Nie jest to jedyny taki projekt w Fundacji.
Wstrząs związany z Heartbleed doprowadził do sypnięcia groszem w stronę OpenSSL. Najwyraźniej jest więcej projektów, które pilnie tego potrzebują. Jednak jak stworzyć ich listę, w którym miejscu postawić granicę i - przede wszystkim - skąd wziąć na to pieniądze?
Obecny model biznesowy nie przewiduje żadnego rozwiązania powyższych problemów, odgórne regulacje byłyby niezwykle trudne do stworzenia, mecenat w oparciu o środki publiczne byłby trudny do wytłumaczenia podatnikom. A problem będzie się stawał coraz większy.
