CVE-2022-21449: Fehler in Java bei Signaturprüfung

[KonradN]

Es gibt einen Fehler in der Signaturprüfung. Ab Java 15 wurde die Prüfung von Signaturen, die bisher in c++ programmiert war, in Java umgesetzt. Dabei wurde aber ein Check auf 0-Werte vergessen, so dass eine Signatur, die ja nur aus zwei Zahlen besteht, gültig ist, wenn zwei Mal eine 0 vergeben wurde.

CVE (Englisch): https://nvd.nist.gov/vuln/detail/CVE-2022-21449

Oracle hat dies bei seinem großen Patch Tag bereits gefixt. OpenJDKs werden da vermutlich auch alle aktualisiert oder wurden schon aktualisiert. Das habe ich jetzt hier aber noch nicht weiter verfolgt.

Ein Beitrag bei Heise: https://www.heise.de/news/Bug-in-Java-macht-digitale-Signaturen-wertlos-6847744.html

Edit: Zu den OpenJDKs evtl. doch noch dieser Link:

OpenJDK Vulnerability Advisory: 2022/04/19

openjdk.java.net

Am 19.4 wurde das behoben - die einzelnen Distributionen müssen das aber natürlich noch übernehmen.

 

[LimDul]

Was ich bei dem Thema erschreckend finde ist die Timeline: https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/

Der wurde am 11. November 2021 gemeldet. Das ist eine riesige Sicherheitslücke und der Fehler ist nach allen was man liest recht trivial auszunutzen, aber auch recht trivial zu fixen. Es gibt laut dem Bericht sogar Standard-Testverfahren sowas zu finden.

Und Oracle braucht geschlagene fünf Monate um eine Korrektur rauszubringen...

Edit: Das einzig gute dürfte sein, dass auf vielen produktiven Systemen, wo so eine Signaturprüfung ggf. läuft, vermutlich nicht so oft Java 15 im Einsatz ist, sondern oft eher auf Java 11 gesetzt wird. Aber trotzdem..

 

[Robert Zenz]

Also soweit ich das sehe: Es gibt die Patch Notes von Oracle, darin steht unter anderem:

CVE-2022-21449 Oracle Java SE, Oracle GraalVM Enterprise Edition Libraries Multiple Yes 7.5 Network Low None None Un- changed None High None Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1, 22.0.0.2 See Note 1

Und unter "Note 1" steht folgendes:

This vulnerability applies to Windows systems only.

Also zum einen, ganz schlecht dass 7, 8 und 11 mitbetroffen sind. Auf der anderen Seite gilt das nur fuer Windows Systeme, also nur sehr weniger Server ddafuer aber viele Clients.

Desweiteren in der CVE Beschreibung:

This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.

Korrigiert mich, aber das klingt zwar uebel, aber nicht so uebel wie es Heise gerne haette.

 

[Jw456]

Frage ist oder war der Fehler in der jetzigen LTS 17 auch vorhanden?

 

[Robert Zenz]

Frage ist oder war der Fehler in der jetzigen LTS 17 auch vorhanden?

Steht doch da: Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18

 

[LimDul]

Also soweit ich das sehe: Es gibt die Patch Notes von Oracle, darin steht unter anderem:



Und unter "Note 1" steht folgendes:



Also zum einen, ganz schlecht dass 7, 8 und 11 mitbetroffen sind. Auf der anderen Seite gilt das nur fuer Windows Systeme, also nur sehr weniger Server ddafuer aber viele Clients.

Desweiteren in der CVE Beschreibung:



Korrigiert mich, aber das klingt zwar uebel, aber nicht so uebel wie es Heise gerne haette.

Ich glaube da Oracle nicht, wenn ich mir die Beschreibung auf https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ ansehe ist Bug, der mit JDK 15 reingekommen ist, deutlich gravierender (mit Proof of Concept). So ganz klar ist mir nicht ,warum dann auch die JDKs vor 15 gefixed werden. Für mich klingt das, was Orcacle da offiziell fixed als etwas anderes, was auf der von mir verlinkten Seite steht. Und mein Vertrauen in Oracle ist da gelinde gesagt gering.

 

[KonradN]

Korrigiert mich, aber das klingt zwar uebel, aber nicht so uebel wie es Heise gerne haette.

Nunja - ich habe mich damit jetzt nicht zu sehr beschäftigt, aber ich würde so Aussagen von Oracle kein Vertrauen schenken. Aber ich stecke da nicht tief genug drinnen und vertraue da eher auf andere Quellen. Heise bringt zwar teilweise auch klickbait aber in der Regel sind so Dinge durchaus gut - alleine schon, weil so falsche Darstellungen in der Regel sehr schnell aktualisiert werden (durch freundliche Hinweise).

Und es gibt ja auch andere Darstellungen und da war @LimDul schneller mit einem weiteren Link.

Und da gilt halt generell: Security ist nichts triviales. Wer da Code schreibt, der muss gefälligst Ahnung haben. Und das ist doch ein Beispiel für absolute Unfähigkeit! Hat da ein Praktikant oder Duali mal Code von C++ nach Java umwandeln zu dürfen? Nicht ohne Grund geben wir hier regelmäßig den Ratschlag, da auf Andere zu vertrauen, die mehr Ahnung haben. Nicht ohne Grund dauerte es Wochen bei FreeBSD bis die Commits einer NSA Mitarbeiters geprüft waren. Man muss sich nur die Angriffsvektoren anschauen, die da gefahren werden: Kleine Schwächungen des Zufallsgenerators sind da an der Tagesordnung. Und sorry: Ich kann das nicht bewerten! Da müssen wirkliche Experten ran! Und selbst das ist keine Garantie! Man muss isch nur anschauen, was z.B. bezüglich OpenSSH / OpenSSL in der Vergangenheit war....

Aber egal - mehr als die Hinweise und meine (sehr laienhafte und in erster Linie emotional begründete) Sicht kann ich auch nicht beitragen.

 

[mrBrown]

Edit: Das einzig gute dürfte sein, dass auf vielen produktiven Systemen, wo so eine Signaturprüfung ggf. läuft, vermutlich nicht so oft Java 15 im Einsatz ist, sondern oft eher auf Java 11 gesetzt wird. Aber trotzdem..

Da wäre ich mir nicht mal sicher, ich würde neuere Java-Versionen grad bei modernen Anwendungen und im Cloud-Umfeld zu finden sein, da dürten zB signed JWTs recht verbreitet sein.

(Von meinen privaten Sachen 100% )

 

[PFEdi]

Hi all,

Ich bin mir gerade nicht sicher ob ich den Security Impact von diesem Problem richtig einschätzen kann …

1) Authentifizierung via Zertifikaten:
Server hat Server-Cert (Private + Public Key)
Für den Client erstellt er ein Zertifikate: Client-Cert + Signiert es mit seinem Private Key mit DSA

1. Client
   1. Erzeugt Request
   2. Signiert Request mit Client-Cert
   3. Sendet Request zum Server
2. Server
   1. Überprüft Client-Cert Signatur
   2. Verarbeitet request
   3. Erzeugt Response
   4. Signiert response mit DSA
   5. Sendet response zum client
3. Client
   1. Empfängt response
   2. Überprüft response mit Server-Cert (Public Key)
   3. Verarbeitet response

Bei der Überprüfung der Client-Cert Signatur am Server (request):
Wenn ein Angreifer selbst ein Zertifikat mit ECDSA erstellt ist dieses ja nicht mit dem Server Zertifikat Signiert (UND ein anderer Algorithmus), würde die Prüfung dennoch funktionieren?

Bei der Überprüfung der Server-Cert Signatur am Cleint (Response):
Wenn ein Angreifer selbst ein Zertifikat mit ECDSA erstellt ist dieses ja nicht mit Server Zertifikat (Public Key) validier bar (anderer Algorithmus), würde die Prüfung dennoch funktionieren?

Worauf ich hinaus will – wenn ich in den Zertifikaten kein ECDSA habe (z.B.: DSA vs ECDSA), dann sollte das doch auch auffliegen?
Beim Signieren selbst kann ich mir ja auch nicht den Algorithmus aussuchen sondern muss den aus dem Zertifikate (Key) nehmen, und nicht irgend einen.
Oder Stimmt das nicht für die Prüfung?

Ja DSA ist nicht so neu, aber vom Prinzip her.

2) ECDSA Problem erst ab Java 15??
Ich dachte erst ggf wurde ECDSA ggf erst später zum JDK hinzugefügt ... aber hier:
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html sehe ich es zumindest auch bei Java 8 -> oder sind die Provider nicht per default dabei.
bzw: https://stackoverflow.com/questions/49181750/ecdsa-isnt-suported-in-java-1-8

 

[LimDul]

Vorneweg - tief hab ich mich da auch nicht eingelesen, also keine Gewähr für 100% Korrektheit.

Fangen wir hinten an.

Das das Problem erst seit Java 15 drin ist, liegt daran, dass der Algorithmus von C nach Java portiert wurde. In C war der 0 Check korrekt drin, in Java nicht. Dementsprechend kam dadurch das Problem rein, auch wenn es den Algorithmus schon vorher gab.

Der Angriff funktioniert wie folgt:
Der Angreifer erstellt gar kein "echtes" Zertifikat, sondern ein leeres. Und dieses leere Zertifikat wird dann als ok erkennt.

Interessant ist das wohl vor allem hier: https://de.wikipedia.org/wiki/JSON_Web_Token

Sprich, gegenüber einer API C kann ich behaupten, hey ich bin XY und habe folgende Berechtigungenen, bestätigt durch den Auth-Provider Z.
Die API überprüft nun, ob diese Behauptung wirklich korrekt ist, indem sie überprüft ob dieses Token wirklich von Auth Provider Z unterschrieben wurde. Und wenn ja, gewährt sie Zugriff auf die entsprechenden Resourcen.

Schicke ich nun ein 0-Signatur mit, sagt diese Überprüfung "ok" obwohl es gar nicht unterschrieben.

Sprich ich kann gegenüber der API mich mit beliebigen Rechten ausstatten.

 

[mrBrown]

Hier ist noch ein Beispiel was die Problematik verdeutlicht: https://github.com/khalednassar/CVE-2022-21449-TLS-PoC

 

[PFEdi]

Vorneweg - tief hab ich mich da auch nicht eingelesen, also keine Gewähr für 100% Korrektheit.

Ich werde dich aber darauf festnageln

Das das Problem erst seit Java 15 drin ist, liegt daran, dass der Algorithmus von C nach Java portiert wurde. In C war der 0 Check korrekt drin, in Java nicht. Dementsprechend kam dadurch das Problem rein, auch wenn es den Algorithmus schon vorher gab.

Ah stimmt.

Der Angriff funktioniert wie folgt:
Der Angreifer erstellt gar kein "echtes" Zertifikat, sondern ein leeres. Und dieses leere Zertifikat wird dann als ok erkennt.

Naja leer kann es ja nicht sein - es muss ja drinnen stehen:
* Wer es ausgestellt hat (wem wollen wir vertrauen: Dem Server)
* Welcher signatur Algorithmus (damit der Fehler zum tragen kommt: ECDSA)
* und dann die Parameter (R =S=0)

Wenn ich die damit erstellte Signatur jetzt überprüfe, muss mir schon bei der Selektion des Algorithmus auffallen, dass ich das nicht verifizieren kann.
Denn ich habe nicht die Möglichkeit die ECDSA zu überprüfe, den im Public Key wurde RSA verwendet.
Sprich BEVOR ich noch überprüfe ob die Signatur in sich stimmt (was sie wird weil R=S=0) könnte ich nicht verifizieren das sie mit dem Server zusammen stimmt (Algorithmen miss-match so zu sagen).

So mein gedanken gang.

 

[KonradN]

Das Problem ist, dass die Signatur selbst unter dem Strich aus zwei Zahlen besteht. Und dann wird multipliziert und am Ende muss etwas gleich sein. Durch 0 Werte wird bei der Multiplikation alles 0 und am Ende hat man immer ein 0 = 0 -> Signatur ist ok.

Daher ist egal, was für eine Signatur du nimmst. Das kann vom Papst sein. Da nimmst Du Dir den public key und die Signatur und so und rechnest und kommst am Ende auf 0 = 0 was wahr ist. Also ist die Signatur gültig! Der Papst hat unterschrieben!

Der Heise Beitrag hat das etwas erläutert. Da einfach noch einmal nachlesen. Und wichtig ist halt: Es muss ein Check stattfinden: Sind die Werte der Signatur 0? Dann ist die Signatur ungültig. Diese Prüfung fehlte bei der Umstellung von C auf Java.

 

[PFEdi]

Wenn ich mir hier das beispiel ansehe:

CVE-2022-21449: Psychic Signatures in Java

The long-running BBC sci-fi show Doctor Who has a recurring plot device where the Doctor manages to get out of trouble by showing an identity card which is actually completely blank. Of course, thi…

neilmadden.blog

|  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]
blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }
jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized>
jshell> sig.initVerify(keys.getPublic())
jshell> sig.update("Hello, World".getBytes())
jshell> sig.verify(blankSignature)
$8 ==> true
// Oops, that shouldn't have verified...

Funktioniert es nur wenn der Algorithmus
Signature.getInstance("SHA256WithECDSAInP1363Format"); -> aus der Signatur
KeyPairGenerator.getInstance("EC").generateKeyPair(); aus dem Key
zusammen passen.
Tun sie das nicht wird nicht weiter geprüft ob die Signatur stimmt.

 

[KonradN]

Aber das ist doch der public key. Und klar - der muss stimmen.

Das ist ja wie der Name. Wenn ich als PFEdi unterschreiben will, dann muss da auch stehen: Das ist die Unterschrift von PFEdi. Da zu schreiben: Das ist die Unterschrift von Otto würde den Check, ob PFEdi unterschrieben hat, nicht erfüllen.

Das Problem ist aber doch, dass das Unterschrift-Feld leer ist. Es reicht also, dass da steht: Unterschrift von PFEdi und schon wird akzeptiert (Es gibt keine Unterschrift, die von Deiner abweicht, also ist es ok).

 

[PFEdi]

Hmmm ich denke nicht ganz so. Ich nutze den PublicKey ja nicht zum Signieren (das macht der Private).
Aber zum Validieren (sonnst kann ich ja immer ein passendes Paar schicken).

Hier ein beispiel

"C:\Program Files\Java\jdk1.8.0_121\bin\keytool.exe" -genkeypair -alias senderKeyPair -keyalg RSA -keysize 2048 -dname "CN=MyName" -validity 365 -storetype PKCS12 -keystore sender_keystore_RSA.p12 -storepass password

// Public Key bla bla lass ich mal weg

String messageString = "Hello CVE-2022-21449!";
byte[] messageBytes = messageString.getBytes();

// sender
Signature signer= Signature.getInstance(algo_to_sign);            // "SHA1withRSA"
signer.initSign(privateKey);                                    // Private Key RSA
signer.update(messageBytes);
byte[] signatureBytes signer.sign();

// receiver
Signature verifier = Signature.getInstance(algo_to_verify);        // "SHA1withRSA"
verifier.initVerify(publicKey);                                    // Public Key RSA
verifier.update(messageBytes);
verifier.verify(signatureBytes);                                // true? false?

Der Sender bereitet das signieren mit "SHA1withRSA" vor und initialisiert das mit dem Private Key der auch RSA ist.
Beim Empfänger wird dann auch "SHA1withRSA" als Algorithmus genutzt um die Signatur zu prüfen (algo_to_verify).

Das muss der selbe sein wie im PublicKey, sonst kann es Mathematisch NIE funktionieren.

Wenn jetzt also eine Message die daher kommt, die mittels ECDSA signiert ist mit R=S=0 interessiert das den Empfänger nicht.
Sein PublicKey ist RSA also kann er nur damit abgleichen. Die Zahlen die er verifizier passen nicht.

Wenn ich den Wert für algo_to_verify auf etwas anderes setzte (irgend etwas mit DSA oder auch ECDSA),
schlägt die initialisierung (verifier.initVerify(publicKey)) mit fehl.
Man kann nicht eine ECDSA signatur mit einem RSA Key validieren, das macht keinen Sinn - und scheinbar ist diese Logik prüfüng zuvor nicht der C zu Java migration zum opfer gefallen, da sie sich nciht auf den mathematischen Alorithmus bezieht.

Es kann natürlich in der Freien Wildbahn gut vorkommen, dass ich nicht nur einen PublicKey habe mit RSA sondern auch mehrere (wie dann der match versucht wird zu erzeugen weiß ich nicht, ggf alle durch probieren oder die eingehende nachricht sagt welcher es sein darf).

Ich hoffe so versteht man meine Gedanken und Verständniss.


PS: Danke für die Antworten.

 

[LimDul]

ich verstehe nicht, warum du dich auf RSA versteifst?
Hier ein Proof of Concept: https://github.com/DataDog/security...pt-exploits/jwt-null-signature-vulnerable-app

Der Algorithmus wird vom Sender mitgeliefert. Er sagt hier ist mein JWT Token, es wurde mit folgendem Algorithmus signiert. Und der ist ECDSA.

https://www.scottbrady91.com/jose/jwts-which-signing-algorithm-should-i-use.

Das einzige ist, du musst wissen, welche Public Keys der Server kennt, was aber nicht unbedingt unmöglich ist für öffentliche Services.

 

[PFEdi]

ich verstehe nicht, warum du dich auf RSA versteifst?

Es geht nicht um "RSA" an sich, es geht um "NICHT ECDSA".
(Daher auch in meinem ersten beispiel nicht RSA sondern DSA)

Warum versteifst du dich auf JWT? (Das ist ja auch nur on top)

Hier ein Proof of Concept: https://github.com/DataDog/security...pt-exploits/jwt-null-signature-vulnerable-app

Der wird eben mit SignatureAlgorithm.ES256 initialisiert (also eine EC).
Ich wiederspreche ja auch nicht das es in solchen fällen funktioniert (falls das so rübergekommen ist, tut mir leid).
Aber wenn kein EC PublicKey genutzt wird, dann geht es nicht - war am Anfang meine frage.

Das einzige ist, du musst wissen, welche Public Keys der Server kennt, was aber nicht unbedingt unmöglich ist für öffentliche Services.

Klar wenn eine Interesannte Entität (eben der AuthN&Z Provider) einen solchen hat, ist das ... Problematisch.
Wenn nicht ... nicht.

 

[KonradN]

OK, sorry, dass ich Dich bisher missverstanden habe.

Aber wenn kein EC PublicKey genutzt wird, dann geht es nicht

Die Lücke betrifft explizit EDSA - damit ist RSA und Co außen vor.

Dazu z.B. der schon im ersten Post verlinkte Heise Artikel:

Bug in Java macht digitale Signaturen wertlos

Doctor-Who-Fans wollen es schon lange: "Psychic Paper" präsentiert dem Opfer scheinbar echte Ausweise aller Art. Ein Fehler in Java macht das zum Kinderspiel.

www.heise.de

Der Fehler betrifft digitale Signaturen auf Basis des weit verbreiteten Elliptic Curve Digital Signature Algorithms (EDSA).

Für Entwickler hat Madden noch einen weiteren Tipp parat: Oft nutzen Programme beziehungsweise Protokolle digitale Signaturen, um die Echtheit von (übertragenen) Daten sicherzustellen; dabei wäre in vielen Fällen der Einsatz eines kryptografischen Hash-Verfahrens mit einem zuvor ausgetauschten Shared Secret (Hash-basierter Message Authentication Code, kurz HMAC) viel einfacher und vor allem weniger fehleranfällig.

Wenn Du also auf RSA setzt und nicht auf EDSA, dann trifft Dich dieses Problem nicht.

Da macht es ggf. auch Sinn, einfach einmal etwas mehr zu den Verfahren zu lesen (aber dabei noch an der Oberfläche zu bleiben):

What is ECDSA Encryption? How does it work? | Encryption Consulting

Elliptic Curve Digital Signature Algorithm, or ECDSA, is one of the more efficient public key cryptography encryption algorithms.

www.encryptionconsulting.com

What is RSA? How does an RSA work? | Encryption Consulting

RSA is a public-key encryption algorithm that uses an asymmetric encryption algorithm to encrypt data. RSA is the primary method of encrypting data-in-motion.

www.encryptionconsulting.com

Da erkennt man dann auch, dass es da um komplett getrennte Verfahren geht und dass ein Implementierungsproblem des einen Verfahrens nicht das andere betreffen.

 

[LimDul]

Es geht nicht um "RSA" an sich, es geht um "NICHT ECDSA".
(Daher auch in meinem ersten beispiel nicht RSA sondern DSA)

Warum versteifst du dich auf JWT? (Das ist ja auch nur on top)

Weil da die größte Gefahr nach meinem Verständnis ist. Eben aus den Gründen, dass der Algorithmus (zum Teil) unter der Kontrolle des Angreifers ist, der Algorithmus da soweit ich das sehe durchaus oft verwendet wird.
Sprich der Angreifer muss nur Auth-Provider finden, der:
* ECDSA verwendet
* Von dem System, wo ich rein will, akzeptiert wird

Der wird eben mit SignatureAlgorithm.ES256 initialisiert (also eine EC).
Ich wiederspreche ja auch nicht das es in solchen fällen funktioniert (falls das so rübergekommen ist, tut mir leid).
Aber wenn kein EC PublicKey genutzt wird, dann geht es nicht - war am Anfang meine frage.


Klar wenn eine Interesannte Entität (eben der AuthN&Z Provider) einen solchen hat, ist das ... Problematisch.
Wenn nicht ... nicht.

Da haben wir glaub ich aneinander vorbeigeredet, da hast du vollkommen Recht. Es müssen Konstellationen vorliegen (ECDSA als Public/Private Key Algo eine der Haupt-Voraussetzungen), dass die Lücke ausnutzbar ist. Kritisch ist sie halt, weil das jetzt nichts total obskures/seltenes ist (bei spring4shell war das schon mal relativ eingeschränkt, was vor liegen musste z.B.) und wenn die Konstellation vorliegt, kann man ein derartig abgesichertes System komplett kompromittieren. Ich hatte dich so verstanden, als würdest du dem CVE generell absprechen kritisch sie zu sein. Und das ist ja nicht der Fall.

Klar ist - es ist beileibe nicht jede Authentifizierung betroffen, es müssen entsprechende Konstellationen vorliegen. Die sind aber nicht komplett obskur und esoterisch, aber jetzt auch nicht der Standard.

 

[PFEdi]

OK, dann ist jetzt alles klar