(nem hivatalos e-kormányzati témájú oldal)
| Mottó: What you gonna be, What you gonna be, brother Zero the hero /Black Sabbath: Zero The Hero/ | ||
| 2022. április 19. | ||
| ECDSA: Oracle Java SE, CVE-2022-21449, Psychic Signatures | ||
| Leírás Az elliptikus görbékkel a nagyoknak is meggyűlik a baja: a Microsoft Windows CryptoAPI-t érintő, 2020-01-14-i hibája (CVE-2020-0601, ld. ECDSA: Előre curve-ák, gengszterek! bejegyzést) után most, a 2022-04-19-i bejelentéssel az Oracle Java SE keretrendszer is elesett (CVE-2022-21449). A 2022-04-19-én nyilvánosságra hozott, de már 2021-11-15-én bejegyzett CVE-2022-21449 jegy szerint az Oracle több megoldásánál, közöttük az alább elemzett Oracle Java SE keretrendszernél sérülékenység található az ECDSA aláírások ellenőrzésénél. A CVE/NVD leírásoknál csak az Oracle Java SE 17.0.2 és 18 kerül említésre, viszont a hivatalos gyártói oldalon, az Oracle listázza ezeken kívül a 7u331, 8u321 és 11.0.14 verziókat is (gyors megjegyzés, hogy a RedHat saját build táblázatánál viszont ezek nem szerepelnek). A pontosításra a jelen esetben nagy szükség van, hiszen ez utóbbiakat, legacy okok miatt is sok helyen alkalmazzák még, ezért az alábbi elemzésben az Oracle Java 8 különböző alverzióit vizsgáltuk meg.
Az elemzések alapján - a "jarsigner -verify" parancsok és a PoC kód futtatásánál, bár eltérő kimeneteket kaptunk a különböző Oracle Java SE verziókat használva, de - úgy tűnik, hogy az Oracle - CVE-2022-21449 jegyhez tartozó - listája nem pontos, legalábbis az Oracle Java SE 8u321 - és 8u112, 8u202 - verziója nem érintett a sérülékenység kapcsán! Az Oracle Java SE 17.0.2 verzió érintettségét viszont meg tudjuk erősíteni! Először úgy tűnt, hogy ott is csak azok a rendszerek téveszthetők meg, amelyek az aláírás ellenőrzésénél az ECDSA aláírást nem ASN.1(r,s) adatstruktúraként, hanem ASN.1() keret nélküli, nyers (r,s) adatstruktúraként kezelik, de később kiderült, hogy még az ASN.1() keretet elemző rétegen is átcsusszanhat a 0 értékű aláírás. Így tehát akár "SHA256WithECDSAInP1363Format" paraméterezésű, nyers (r,s) adatstruktúra, akár "SHA256withECDSA" paraméterezésű, ASN.1(r,s) adatstruktúra jön létre, az ellenőrző fél oldalán nem lehet észrevenni, ha valami módosítja az üzenetet és annak digitális aláírását. Érdemes megjegyezni, hogy a "SHA256WithECDSAInP1363Format" paraméterezés még nem volt támogatott az Oracle Java SE 8 változatban, így a nyers (r,s) adatstruktúra ellenőrzésére hibát dobott az a Java keretrendszer. Érdekesség viszont, hogy az Oracle Java SE 9 verzióban megjelent a "SHA256WithECDSAInP1363Format" paraméterezés, de csak az Oracle Java 17.0.2 verziótól létezik a sérülékenység. Érdekesség továbbá az is, hogy a Java keretrendszer képes az ASN.1() keretes adatstruktúrákat is megengedőbb módon feldolgozni az "allowBER" engedélyezése révén (és ilyenkor érvényre is juthat a sérülékenység!), azonban ez kívülről nem állítható/módosítható! Mindezektől függetlenül, mivel végül sikerült mind ASN.1(r,s), mind nyers (r,s) adatstruktúráknál is érvényre juttatni a sérülékenységet, azt lehet mondani, hogy a legtöbb jelenleg használt protokoll, aláírásformátum érintett lehet sérülékeny Java esetén! A sérülékenység kihasználása azonban nem csak az ECDSA aláírást ellenőrző fél oldalán futó Java verziótól (pl. Oracle Java SE 17.0.2), hanem az általa használt crypto library-től is függ (pl. Bouncy Castle, Apache Santuario nem érintett). Milyen protokollok, aláírásformátumok használhatnak ASN.1(r,s) vagy nyers (r,s) adatstruktúrájú ECDSA aláírást?
Függelék A JWS (JSON Web Signature) aláírásoknál (ES256), nyers (r,s) adatstruktúránál lehet a legkönnyebben végrehajtani a támadást olyan félnél (pl. kliens), ami sérülékeny Oracle Java SE (pl. 17.0.2) révén ellenőrzi az ECDSA aláírásokat, majd miután azokat hibásan érvényesnek találja a Java keretrendszer, az üzenetben található adatokat feldolgozza (pl. a szabványból vett mintában egy "joe" számára "root" hozzáférési jogosultságot igazoló adat van ECDSA aláírással védve, amiben a jogosult azonosítója könnyedén, észrevétlenül lecserélhető, sérülékeny Java keretrendszernél).
A CVE_2022_21449.class állomány futtatásánál az ECDSA aláírás ellenőrzésére az első hívás az eredeti (érvényes), a második a módosított (érvénytelen - negative test), a harmadik a módosított (érvényes - 00 byte-okkal, sérülékenység esetén) ASN.1(r,s) vagy nyers (r,s) adatstruktúrával került végrehajtásra. Ezeknél látszik, hogy csak az Oracle Java SE 17.0.2 keretrendszernél kaptunk hibás, "érvényes" eredményt a 00 byte-okkal feltöltött, ASN.1(r,s), illetve nyers (r,s) adatstruktúrájú ECDSA aláírások ellenőrzésénél. Oracle Java SE 8u112 (SHA256withECDSA esetén)
Kapcsolódó anyagok:
| ||
| vissza | ||
info@ugyfelkapu.info
