Ethereum-Clients Teku und Besu patchen Schwachstellen, die Validator-Belohnungen gefährdeten
Wichtige Erkenntnisse
- •Teku veröffentlichte Version 26.10.3 am 27. Oktober und Besu lieferte Version 26.10.2 am 26. Oktober aus; beide Updates entfernen die betroffenen eMudhra-Zertifizierungsstellen aus den Docker-Images, die zum Betrieb von Ethereum-Knoten verwendet werden.
- •Die Zertifikatsschwäche entstand, weil acht eMudhra-Intermediate-Zertifikate auf privaten Schlüsseln basierten, die Angreifer aus öffentlichen Informationen berechnen konnten, und Javas standardmäßiges Unterlassen der Widerrufsprüfung die Java-basierten Clients selbst nach dem Widerruf gefährdet ließ.
- •Teku warnte, dass eine gefälschte Verbindung zu einem Remote-Node oder externen Signing-Dienst Block-Gebühren und Belohnungen hätte umleiten können; ein standardmäßiger Mainnet-Node erforderte jedoch keine Maßnahmen, und es wurde keine Ausnutzung gemeldet.
- •Ein Einlagen-Routing-Fehler in den Glamsterdam-Entwurfsregeln, identifiziert vom Forscher avsetsin, hätte Staking-Einlagen in das Konto eines Builders umleiten können, wenn ein Builder und ein Validator einen öffentlichen Schlüssel teilten; die überarbeiteten Regeln sortieren ausstehende Einlagen nach Withdrawal-Credentials und wurden am 26. Oktober gemergt, nachdem Client-Teams sie zunächst abgelehnt hatten.
- •Node-Betreiber, die Teku oder Besu außerhalb von Docker betreiben, müssen Java separat aktualisieren; Teku empfahl Nutzern des nicht unterstützten Java 26 den Wechsel zu Java 25, und das Hoodi-Testnet-Upgrade wurde bis auf Weiteres verschoben.
Ethereum-Entwickler haben zwei separate Schwachstellen behoben, die Validator-Einlagen und Block-Belohnungen hätten gefährden können: eine betraf schwache Website-Zertifikate, die andere war in den Entwurfsregeln für das bevorstehende Glamsterdam-Upgrade des Netzwerks enthalten. Teku, ein Consensus-Client, und Besu, ein Execution-Client, veröffentlichten jeweils Patches zur Behebung der Schwachstelle. Ethereum-Knoten betreiben parallel einen Consensus-Client und einen Execution-Client, sodass beide Ebenen des Node-Stacks dieselbe Zertifikatsbereinigung benötigten.
Teku veröffentlichte Version 26.10.3 am 27. Oktober, einen Tag nachdem Besu Version 26.10.2 am 26. Oktober ausgeliefert hatte. Beide Releases entfernen die betroffenen Zertifizierungsstellen aus den Docker-Images, die zum Betrieb von Ethereum-Knoten verwendet werden, wie auf Tekus Release-Seite zu sehen ist.
Schwache Zertifikatsschlüssel entdeckt
Forscher stellten am 17. Oktober fest, dass acht Intermediate-Zertifikate der indischen eMudhra auf privaten Schlüsseln basierten, die Angreifer aus öffentlich verfügbaren Informationen berechnen konnten. Mit diesen Schlüsseln hätten Angreifer Zertifikate für gefälschte Dienste ausstellen können. eMudhra widerruf die Zertifikate, doch einige Java-Installationen vertrauten ihnen weiterhin, da Java standardmäßig keine Zertifikatswiderrufe prüft. Sowohl Teku als auch Besu sind in Java geschrieben – so gelangte die Schwachstelle in den Betrieb von Ethereum-Knoten.
Die Entdeckung fiel in dieselbe Woche, in der Google ein Krypto-Verwahrsystem zur Sicherheit vorstellte, das private Schlüssel auf separate Umgebungen verteilt.
Wie Validator-Gebühren hätten umgeleitet werden können
Der Zertifikatsfehler war relevant, weil Validatoren auf Verbindungen zu externen Diensten angewiesen sind. Ein Angreifer, der eine solche Verbindung abfangen konnte, könnte sich als der Dienst am anderen Ende ausgeben. Teku warnte, dass eine gefälschte Verbindung zu einem Remote-Node dazu führen könnte, dass Block-Gebühren an eine angreiferkontrollierte Adresse gezahlt werden. Externe Signing-Dienste stellten in betroffenen Konfigurationen ein zusätzlicheres Risiko dar, da Angreifer Signaturen erlangen könnten, die Belohnungen umleiten.
„Ein standardmäßiger Teku-Node im Mainnet ist nicht betroffen und erfordert keine Maßnahmen“, erklärte Teku. Das Client-Team berichtete von keiner bekannten Ausnutzung.
Glamsterdam-Einlagenregeln korrigiert
In einem separaten Vorhaben überarbeiteten die Entwickler die vorgeschlagenen Glamsterdam-Regeln, nachdem der Forscher avsetsin einen Einlagen-Routing-Fehler identifiziert hatte. Zudem verschoben sie das Hoodi-Testnet-Upgrade, das für den 26. Oktober geplant gewesen war.
Nach dem früheren Entwurf hätte ein Builder und ein Validator mit einem gemeinsamen öffentlichen Schlüssel dafür sorgen können, dass Staking-Einlagen in das Konto des Builders gelangen. Glamsterdam soll die Blockerstellung von der Validierung trennen, und der überarbeitete Vorschlag sortiert ausstehende Einlagen nach Withdrawal-Credentials, wodurch Validator-Einlagen von Builder-Einlagen unterschieden werden.
Die Client-Teams lehnten die Korrektur zunächst am 19. Oktober ab, da keine Einigung erzielt wurde. Anschließend fügten die Entwickler Tests hinzu und mergten die überarbeiteten Regeln am 26. Oktober.
Unterschiedliche nächste Schritte für Node-Betreiber
Die Glamsterdam-Korrektur ist in die Spezifikationen von Ethereum eingeflossen, doch die Software-Teams müssen sie noch implementieren. Glamsterdam lief zuvor auf dem Sepolia-Testnet, während Hoodi auf ein neues Aktivierungsdatum wartet.
Betreiber, die Teku oder Besu außerhalb von Docker betreiben, müssen Java separat aktualisieren. Das Zertifikatsrisiko betraf Zahlungen aus Ethereum-Gas-Gebühren, wie an Validatoren gezahlte Priority-Fees, und nicht gewöhnliche Wallet-Guthaben der Nutzer. Teku empfahl Nutzern des nicht mehr unterstützten Java 26, auf Java 25 zu wechseln.
Die Zertifikats-Patches beheben die betroffenen Docker-Images, während der Glamsterdam-Fix noch auf die Übernahme im gesamten Ethereum-Client-Ökosystem wartet.
