JVM Tuesday vol. 85 – Edycja Whoviańska

1. Co wyjdzie z połączonych mocy Javy, “papieru psychicznego” i krzywych eliptycznych? Nie, nie Kapitan Planeta… groźna podatność.

Mój charakter jest jednak dość paskudny. Gdy cała społeczność javowa panicznie łata (kolejną już w ostatnim czasie) bardzo groźną awarię, ja odczuwam satysfakcję z tego, że została ona nazwana na cześć jednego z najdziwniejszych seriali w historii telewizji, przynajmniej tej brytyjskiej. Proszę państwa, oto CVE-2022-21449: Psychic Signatures in Java.

W skrócie (a uwierzcie, mógłbym długo) Doktor to podróżujący w czasie kosmita z  posiadający wiele gadżetów (soniczny śrubokręt, Tardis, cudowny theme muzyczny), ale także pewną niepozorną białą kartkę zrobioną z tak zwanego „psychicznego papieru”: osoba patrząca na niego widzi wszystko, co Doktor chce, żeby zobaczyła. Może to być dowód osobisty, przepustka, nakaz policyjny… pewnie rozumiecie. Dzięki temu niepozornemu gadżetowi główny bohater serialu jest w stanie w bardzo prosty sposób ominąć nawet najlepsze zabezpieczenia. I super, gdy coś takiego potrafi bohater serialu, którego przygody śledzimy, a jemu samemu mocno kibicujemy… trochę gorzej jeśli mówimy o atakującym, który jest w stanie ominąć weryfikację sygnatur w naszej aplikacji.

Okazało się bowiem, że javowy algorytm sygnatur oparty o Kryptografie krzywych eliptycznych posiada komicznie wręcz smutną podatność. Algorytmy eliptyczne ze swojej natury są bardzo skuteczne, ponieważ łączą mały rozmiar kluczy i sygnatur (krótszy string) z bardzo dobrym efektem jeśli chodzi i bezpieczeństwo. W założeniu dokładnie tak samo działo się w wypadku implementacji zawartej w ramach JDK. Niestety, okazało się, że wdarł się w nią błąd i podanie sygnatury składającej się z samych zer… pozwala na poprawne kryptograficzne zweryfikowanie każdej(!) wiadomości.

|  Welcome to JShell -- Version 17.0.1
|  For an introduction type: /help intro
jshell> import java.security.*
jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()
keys ==> java.security.KeyPair@626b2d4a
jshell> var blankSignature = new byte[64]
<strong>blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }
</strong>jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized>
jshell> sig.initVerify(keys.getPublic())
jshell> sig.update("Hello, World".getBytes())
<strong>jshell> sig.verify(blankSignature)
</strong>$8 ==> true
<em>// Oops, that shouldn't have verified...</em>

Więcej technicznych detali zawiera oryginalna informacja o błędzie znajdziecie w oryginalnym blogpoście. Z niego też możecie dowiedzieć się lepiej, jak działają algorytmy eliptyczne i skąd pojawił się taki a nie inny błąd. Jeśli chcecie coś bardziej skondensowanego, całkiem elegancki “skrótowiec” przygotował JFrog. Ale jeszcze zanim przeczytacie któryś z tekstów, najlepiej zaktualizujcie Wasze maszynki (albo chociaż zróbcie ticket w Jirze, żeby nie uciekło) – o ile CVE według Oracle ma poziom 7.5, to w przypadku niektórych aplikacji efekt może być równy zostawienia drzwi otwartych i poinformowaniu na facebooku, że jedziecie na wakacje. 

Źródła

• CVE-2022-21449: Psychic Signatures in Java – Neil Madden
• https://pl.wikipedia.org/wiki/Kryptografia_krzywych_eliptycznych
• CVE-2022-21449 “Psychic Signatures”: Analyzing the New Java Crypto Vulnerability

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. Gradle Enterprise wprowadzi uczenie maszynowe do Twojego buildu

Skoro już te realnie ważne (nie bagatelizujcie!) rzeczy mamy za sobą, czas na trochę ciekawej trivii. Czy wiecie bowiem, że Gradle posiada swoją wersję Enterprise? Jeśli się nad tym zastanowić, nic jakoś szczególnie zaskakującego w tym fakcie nie ma (każdy produkt musi na czymś w końcu zarabiać), ale w dalszym ciągu mnie osobiście ten fakt mocno umknął. Okazuje się, że mają też niemało klientów z dość znanymi logami, żeby wymienić tutaj tylko LinkedIna, Netflixa czy Salesforce.

W tym miejscu pewnie zastanawiacie się, co takiego Gradle Enterprise ostatecznie oferuje. W ich obszarze zainteresowania znajdują się szeroko pojęte “developers productivity”, na które składają się rozproszone cache dla buildów mające przyspieszyć ich trwanie czy też  ułatwienia w wykrywaniu przyczyn faili budowania czy “flejkujących” testów. Pakiet udostępnia też narzędzia, które ometrykowują nasze procesy budowania w sposób umożliwiający ich lepszą późniejszą optymalizację. 

Dlaczego jednak piszemy o tym akurat w bieżącej edycji? Otóż w zeszłym tygodniu ukazał się komunikat prasowy, będący zapowiedzią nowego feature. Cóż takiego szykuje nam Gradle? Inżynierowie firmy zagonili algorytmy uczenia maszynowego, aby wykrywać, które testy należy odpalać, a które można sobie odpuścić. Podobno pierwsze wyniki są naprawdę obiecujące… przynajmniej w komunikatach partnerów, którzy mieli już okazję całość testować. Przy czym wiecie… papier (a zwłaszcza komunikat PR-owy) wszystko wstrzyma.

Fajnie, ale “osiąganie lepszej produktywności programistów za pomocą uczenia maszynowego” w moich uszach brzmi trochę jak zlepek buzzwordów dla inwestorów (predyktywne! uczenie maszynowe!), choć pewnie Ci dokładnie tego oczekiwali. W listopadzie zeszłego roku Gradle pozyskało bowiem swoją trzecią rundę finansowania, a wraz z nią 27 milionów dolarów – co nie jest wynikiem oszałamiającym, ale biorąc pod uwagę, że mówimy o toolingu (nawet jeśli bardzo popularnym) to dalej ładna sumka wpadła. Ciekawe, co następnego Gradle nam szykuje? 

Źródła

• Gradle Inc. Raises $27 Million in Series C Funding
• Customers | Gradle Enterprise
• Developer Productivity Gets a Boost from Machine Learning | Gradle Enterprise

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. Kolejne podejście WildFly do bycie “chmuronatywnym”

A na koniec będzie szybko – WildFly wydaje drugą wersję swojej wersji “cloud native”.

Pod skrótem WildFly S2I kryje się rozwinięcie Source-to-Image (S2I). Mówimy tutaj o zestawie narzędzi, na który składają się nowe bazowe obrazy dla javowych LTS w wersji JDK11 i JDK17 (brak ósemki), nowy plugin mavenowy, zestaw chmurowych funkcjonalności o wdzięcznej nazwie Galeon oraz nowa wersja wsparcia dla Helm dla WildFly 2.0.

Ja wiem, że Cloud-Native serwer Enterprisowej Javy brzmi jak pewnie kuriozum, ale twórcy w tym wypadku naprawdę się postarali. Przygotowali kilkanaście (!) różnego rodzaju tutoriali i masę innej dokumentacji. Widać, że chcą jeszcze trochę powalczyć na nowym terytorium. WildFly zawsze uchodził za tego najbardziej “światowego” członka społeczności Jav… Jakarta EE, także podejrzewam, że wśród jego użytkowników znajdą się tacy, którzy będą mieli ochotę z S2I poeksperymentować. Jakby ktoś miał okazję używać – podzielcie się proszę wrażeniami. Ja wypadłem ze świata Cloud-Native J2EE jeszcze na etapie świętej pamięci Swarma – który zresztą też był projektem WildFly.

Źródła

• WildFly S2I new architecture is final!
• WildFly Swarm Initial Release