eMudhra-Zertifikatsfehler veranlasst Teku- und Besu-Docker-Korrekturen; Binärnutzer müssen Java separat prüfen
Die Ethereum-Client-Software Teku und Besu hat Docker-Updates veröffentlicht, die das Vertrauen in vier Zertifikatswurzeln entfernen, die mit einer Kompromittierung der Zertifizierungsstelle eMudhra in Verbindung stehen. Binärinstallationen müssen die von ihnen genutzte Java-Laufzeitumgebung separat prüfen, da ein Update des Clients diese nicht verändert.
Verfasst von der KI-Redaktion von CoinArticle · auf Basis von 2 angegebenen Quellen. So arbeiten wir
Was die Releases ändern
Teku 26.10.3, veröffentlicht am 27. Oktober, und Besu 26.10.2, veröffentlicht am 26. Oktober, sorgen dafür, dass ihre Docker-Images nicht mehr auf vier Zertifikatswurzeln vertrauen: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 und AAA Certificate Services. Die Korrekturen betreffen die mitgelieferten Trust-Stores, also die Listen der Zertifizierungsstellen, die Java standardmäßig akzeptiert.
Beide Projekte beschränken die Korrektur auf Container. Besu erklärt, dass seine tar- und zip-Distributionen möglicherweise weiterhin ein JDK verwenden, das den betroffenen Wurzeln vertraut. Die Binärdistribution von Teku nutzt die Java-Laufzeitumgebung, die der Betreiber installiert hat; diese Betreiber müssen daher prüfen und gegebenenfalls diese Laufzeitumgebung unabhängig vom Client korrigieren.
Der eMudhra-Vorfall
Dem Problem lagen wiederherstellbare private Schlüssel für acht emSign-G3-Zwischenzertifizierungsstellen zugrunde. Laut der Vorfallerklärung von eMudhra meldete ein Forscher die schwachen Zwischenzertifikate am 17. Oktober, und das Unternehmen widerrief alle acht am folgenden Tag. eMudhra räumte einen Skriptfehler ein, der die schwachen Schlüssel erzeugte.
Die Berichterstattung unterscheidet sich darin, wie die Schlüssel ausgenutzt wurden. Der Bericht des Go-Sicherheitsteams beschreibt, dass die privaten Schlüssel in Mikrosekunden wiederhergestellt werden konnten, sodass ein Angreifer ein Zertifikat für eine Domain ausstellen könnte, die er nicht kontrolliert. Die Forschung von Kudelski Security untersucht dieselbe Zertifikatshierarchie und beschreibt das Risiko so, dass Software ein mit einem reproduzierbaren Schlüssel signiertes Zertifikat akzeptiert. Der Hinweis von Teku hält fest, dass Java standardmäßig keine Sperrprüfung durchführt, weshalb widerrufene Zwischenzertifikate von nicht korrigierten Laufzeitumgebungen weiterhin akzeptiert werden können.
Exposition hängt von der Konfiguration ab
Die Sicherheitsmitteilung von Teku besagt, dass Standard-Mainnet-Nodes ohne HTTPS-URLs nicht betroffen sind und dass keine Ausnutzung gemeldet wurde. Ein Angreifer auf einer nicht korrigierten Laufzeitumgebung müsste außerdem eine betroffene HTTPS-Verbindung abfangen; der schwache Schlüssel allein versetzt einen Angreifer also nicht zwischen einen Node und seine Peers.
Wo HTTPS-Verbindungen bestehen, unterscheiden sich die Folgen je nach Rolle. Zu den HTTPS-Abhängigkeiten von Teku können Remote-Signer, Beacon-Nodes, Execution-Clients, Builder oder Relays, Metrikdienste und Datenquellen für den Start gehören. Laut der Mitteilung könnte ein imitierter Remote-Beacon-Node Proposal-Gebühren umleiten oder versäumte Pflichten verursachen, und ein imitierter externer Signer könnte Signaturen für Validator-Exits erhalten. Die gegenseitige TLS-Client-Authentifizierung am Signer begrenzt diesen zweiten Fall auf Denial of Service. Die Mitteilung weist außerdem auf Sepolia, Hoodi und Ephemery hin, die beim Start mit leerer Datenbank den Startzustand über HTTPS herunterladen. Die Peer-to-Peer-Vernetzung von Teku, einschließlich libp2p und discv5, verwendet keine Zertifizierungsstellen und fällt nicht unter dieses Problem.
Was Betreiber prüfen sollten
Betreiber sollten zunächst feststellen, ob ihre Konfiguration ausgehende HTTPS-Verbindungen zu den oben genannten Diensten aufbaut. Docker-Nutzer sollten auf die korrigierten Images aktualisieren. Die Mitteilung von Teku besagt, dass alle seine Docker-Images bis einschließlich 26.10.2, einschließlich der Varianten -jdk25 und -jdk26, wiederum die betroffene emSign-ECC-Wurzel enthalten und dass ein Java-Update auf dem Host die Laufzeitumgebung im Container nicht verändert.
Nutzer von Binär- und Archivdistributionen sollten prüfen, welches JDK ihr Node verwendet und ob es den betroffenen Wurzeln noch vertraut. Die Konsensregeln von Ethereum werden durch diesen Vorfall nicht verändert; das Problem betrifft die Software und die Zertifikatsinfrastruktur rund um die Validatoren.
Warum es wichtig ist
Für Trader
Das Risiko im Zusammenhang mit Validatoren ist hier operativer und nicht protokollbezogener Natur. Beobachten Sie daher gemeldete Ausnutzungen oder weitere Client-Releases, bevor Sie Ihr Risiko neu bewerten.
Für Investoren
Der Vorfall verdeutlicht das Risiko von Drittanbieter-Zertifizierungsstellen in der Validator-Infrastruktur, was in den kommenden Monaten beeinflussen könnte, wie Node-Betreiber und Staking-Dienste Sicherheitspraktiken gewichten.
Für Entwickler
Jeder Dienst, der dem Standard-Zertifikatsspeicher von Java vertraut, sollte seine mitgelieferten Wurzeln und die Behandlung von Sperrprüfungen prüfen, da Java standardmäßig keine Sperrprüfung durchführt.
Dieser Artikel dient nur zur Information und stellt keine Finanzberatung dar. Vollständigen Haftungsausschluss lesen.
