要約
- Teku 26.10.3 および Besu 26.10.2 は、 compromis された中間鍵により、eMudhra に関連する証明書ルートの信頼を削除し、一部の HTTPS ベースのバリデーター設定がなりすましのリスクにさらされるのを防ぎます。
- デフォルトのTekuメインネットノードは影響を受けず、悪用は報告されていません。リスクは、バリデータがHTTPSを介して外部サービスに接続するかどうかに依存していました。
- Dockerユーザーはクライアントイメージを更新する必要があります。スタンドアロンオペレーターはJavaを別途パッチ適用する必要があります。Java 26を使用しているユーザーは、サポートされているJava 25ビルドに移行する必要があります。
TekuおよびBesuは、eMudhraの証明書認証機関キーが compromized されたことにより、Ethereumノードの設定が偽造されたHTTPS接続にさらされる事態が発生した後、セキュリティ更新をリリースしました。Tekuのリリースノートでは、Dockerイメージから影響を受けた4つの証明書ルートの信頼を削除するバージョン26.10.3を推奨しており、Besuはバージョン26.10.2をリリースしました。これらの更新は、Ethereumのコンセンサスルールの欠陥ではなく、ソフトウェア配布層における証明書信頼を対象としています。デフォルトのTekuメインネットノードは影響を受けず、この事象はEthereumプロトコルの脆弱性とは明確に区別されます。
compromisされた証明書キーがなりすましのリスクを生み出しました
研究者たちは、8つのeMudhra中間証明機関の秘密鍵が十分なランダム性で生成されていなかったため、復元可能であることを発見しました。これらの証明書は取り消されましたが、Javaはデフォルトで取り消しをチェックしないため、ランタイムが偽造された証明書を受け入れてしまう可能性があります。したがって、ノードとHTTPSサービスの間に位置する攻撃者は、脆弱な構成下でそのエンドポイントを装うことができます。この出来事は、Ethereumクライアントの多様性と運用セキュリティがコンセンサスコードを超えて重要であることを改めて示しています。
最もリスクの高いシナリオは、バリデータがHTTPSを介して外部サービスに接続する場合です。偽造されたエンドポイントは、ブロック構築情報の操作、手数料受取人のリダイレクト、または偽装された外部署名者を通じた署名の取得が可能でした。Tekuは、リモートビーコンノードを使用するバリデータクライアントが、攻撃者のアドレスに手数料を支払うブロックを提案する可能性があると述べました。このリスクは、TekuまたはBesuを実行しているかどうかではなく、ネットワークの位置とリモートサービスの設定に依存します。これまでに悪用された事例は報告されていません。
Teku 26.10.3は、DockerイメージからemSign ECC Root CA G3、emSign Root CA G1、emSign Root CA G2、およびAAA Certificate Servicesの信頼を削除します。Besuの更新も同じアプローチを適用します。バイナリを直接実行しているオペレーターは、クライアントのアップグレードがホストランタイムの証明書ストアを置き換えないため、Javaを別途更新する必要があります。したがって、Dockerデプロイとスタンドアロンデプロイでは、対応方法が異なります。この区別は、Ethereumバリデータインフラストラクチャの事故が、プロトコル外の依存関係がステーキング操作にどのように影響するかを示した後、重要です。
Java 26はライフサイクルが終了し、必要なパッチが提供されないため、影響を受ける運用者はJava 25に移行する必要があります。ピアツーピアのEthereumネットワークは、これらの証明機関に依存しないため、公開されていません。これらの修正により、サードパーティのトラストストアのリスクが軽減されますが、ライブメインネットの脆弱性を修復したり、Ethereumのプロトコルを変更したりすることはしません。この対応は、Glamsterdam入金ルーティングの修正を含むその他のセキュリティ対応に続くものであり、バリデーターの安全性がプロトコルコードと支援インフラに依存していることを示しています。