Ethereum-Clients entfernen vier kompromittierte Zertifikatswurzeln

Teku 26.10.3 und Besu 26.10.2 entfernen nach dem Vorfall bei der Zertifizierungsstelle eMudhra vier Zertifikatswurzeln aus ihren Docker-Images. Tekus Release wurde am 27. Oktober veröffentlicht, das von Besu am 26. Oktober. Betreiber von Binärinstallationen müssen ihre Java-Laufzeitumgebung separat überprüfen.

Warum das wichtig ist

Bei dem Vorfall ging es um wiederherstellbare private Schlüssel für acht Zwischenzertifizierungsstellen von emSign G3. eMudhra erklärte, ein Skriptfehler habe schwache Schlüssel erzeugt. Nach einer Meldung vom 17. Oktober seien die Zwischenzertifikate widerrufen worden. Tekus Sicherheitshinweis warnt, dass Java standardmäßig nicht prüft, ob Zertifikate widerrufen wurden. Der Widerruf allein schützt betroffene Laufzeitumgebungen daher möglicherweise nicht.

Laut Teku sind standardmäßig konfigurierte Ethereum-Mainnet-Knoten ohne HTTPS-URLs nicht betroffen. Es gebe auch keine Hinweise auf eine Ausnutzung der Schwachstelle. Das Risiko hängt von der Konfiguration ab: Ein Angreifer müsste eine betroffene HTTPS-Verbindung abfangen, um sich als deren Endpunkt auszugeben. Teku nennt als mögliche HTTPS-Abhängigkeiten Remote-Signer, Beacon-Knoten, Execution-Clients, Builder, Relays und Validator-Dienste. Das Peer-to-Peer-Netzwerk sei nicht betroffen, da libp2p und discv5 keine Zertifizierungsstellen verwenden.

Auswirkungen auf den Markt

Die Fehlerbehebungen entfernen emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 und AAA Certificate Services aus den Docker-Images. Teku zufolge enthielten seine Docker-Images bis einschließlich Version 26.10.2, darunter die Varianten -jdk25 und -jdk26, noch eine betroffene Zertifikatswurzel. Ein Java-Update auf dem Host aktualisiert nicht die Laufzeitumgebung, die in diesen Containern enthalten ist.

Die Änderung von Besu gilt für Docker-Images. Nutzer der Tar- und Zip-Dateien verwenden möglicherweise weiterhin ein JDK, das den betroffenen Wurzeln vertraut. Auch Teku-Nutzer mit Binärinstallationen sind auf die vom Betreiber installierte Java-Laufzeitumgebung angewiesen. Wird eine betroffene Verbindung abgefangen, könnte sich ein Angreifer als entfernter Beacon-Knoten ausgeben und dadurch möglicherweise Vorschlagsgebühren umleiten oder dazu führen, dass Validatoren ihre Aufgaben versäumen. Teku warnt außerdem, dass die Nachahmung eines erreichbaren externen Signers einem Angreifer Validator-Exit-Signaturen verschaffen könnte. Bei gegenseitiger TLS-Client-Authentifizierung beschränkt sich die genannte Auswirkung auf eine Dienstverweigerung.