Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Tajemnicza podatność w Javie, która… może okazać się katastrofalna. Błąd kryptograficzny związany z podpisami cyfrowymi [CVE-2022-21449]
Jeśli zobaczycie na kwietniowy Critical Patch Update odnośnie Javy, to pewnie machniecie ręką – eee, nic ciekawego.
Więc jeśli już machnęliście ręką, warto zapoznać się z tym wpisem: CVE-2022-21449: Psychic Signatures in Java.
Problem występuje w implementacji algorytmu podpisu ECDSA. Ultra krótkie wprowadzenie do problemu:
ECDSA stands for the Elliptic Curve Digital Signature Algorithm, and it is a widely used standard for signing all kinds of digital documents. Compared to the older RSA standard, elliptic curve keys and signatures tend to be much smaller for equivalent security, resulting in them being widely used in cases where size is at a premium. For example, the WebAuthn standard for two-factor authentication allows device manufacturers to choose from a wide range of signature algorithms, but in practice almost all of the devices manufactured to date support ECDSA signatures only (a notable exception being Windows Hello, which uses RSA signatures; presumably for compatibility with older TPM hardware).
Okazuje się, że wystarczy dla dowolnej wiadomości wygenerować „pusty podpis” (same zera) i taki podpis będzie prawdziwy:
Podatne są (tj. były): Java 15, Java 16, Java 17, Java 18 (łatka Oracle wskazuje jako podatne wersje: 7u331, 8u321, 11.0.14, 17.0.2, 18 – lub (w danej linii?) niższe). Polecamy dość szybko zaaplikować łatkę, w szczególności jeśli gdzieś bazujecie na podpisach wykorzystujących krzywe eliptyczne (patrz np. JWT i algorytmy ES*)
~Michał Sajdak
W artykule jest błąd. Podatne są też wersje javy: Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18;
Hmmm, te wersje Javy (podane u nas) podaje oryginalny wpis badaczy, w każdym razie po zaaplikowaniu linkowanego fixa. Ale też robimy update w tekście.
Na https://openjdk.java.net/groups/vulnerability/advisories/2022-04-19 są dla CVE-2022-21449 zaznaczone tylko 15+
Hmmm, ktoś się ostro wziął za badanie JAVA: log4shell, spring4shell, a teraz to. Ciekawe co będzie dalej?
Inna sprawa, że w korporacjach w końcu zaczyna upadać mit: „to jest w java, więc to jest z założenia bezpieczne”.
Wszędzie czytam o nowościach, przestarzałych technologiach a ciągle ten upośledzony archaizm się pojawia. Rozumiem fascynację Javą wśród programistów tejże, ale pozostali?
Bezpieczeństwo w tym czymś nigdy nie istniało.
To tylko w Oraclowej Javie? OpenJDK i inne implementacje też się łapią?
Tutaj commit z fixem (do jdk17)
https://github.com/openjdk/jdk17u/commit/2d4103a3d929e05edca98e7703e0869077966be7
niestety wersja 17.0.3 jeszcze nie została wydana, a 17.0.2 jest podatna :/ ktoś ma pomysł jak to fixnąć? czy pozostaje czekać na 17.0.3 ?