TekuとBesuがEthereum(ETH)の検証者向け欠陥を修正、eMudhra証明書の信頼を削除

Teku 26.10.3とBesu 26.10.2

イーサリアム (ETH)のクライアントソフトウェアに、外部証明書を巡る修正が相次いで入った。Tekuの開発チームは火曜日にバージョン26.10.3を、Besuは月曜日にバージョン26.10.2をそれぞれリリースし、双方ともインドのeMudhra社に由来する証明書への信頼をDockerイメージから取り除いた。変更内容は、Teku 26.10.3とBesu 26.10.2の公式リリースノートに記録されている。この修正は、最もリスクの高い運用形態において攻撃者が気付かれないまま一部の検証者報酬を任意のアドレスへ誘導できた経路を塞ぐものだ。コンセンサスのルールが破られた事実はなく、Tekuチームはこれまでに悪用の報告がないことを確認している。

検証者とは、ステークを預け入れてEthereumのコンセンサスメカニズムであるプルーフオブステーク型のブロックチェーンを支えるコンピュータのことで、ブロックの提案と引き換えに手数料を受け取る。その一部はインターネット経由で外部サービスと通信し、相手先の真正性を確認するためにデジタル証明書に依存している。問題があったのはこの周辺の仕組みであって、プロトコルそのものではない。Ethereum(ETH)の価格が侵害された証明書に依存することは一度もないが、検証者が得る手数料と報酬は影響を受けた道具立てを通じて流れる。

発端は10月17日の発見だった。調査者らは、eMudhraの中間認証局8つの背後にある秘密鍵が、乱数の取り得る範囲が狭すぎる状態で生成されていたと突き止めた。証明書は公開文書であるため鍵は証明書そのものから復元でき、鍵を手にした者は未修正のソフトウェアが本物と受け入れる証明書を偽造できた。ブラウザが真っ先に動き、当該証明書の受け入れを停止した。eMudhraは翌日に証明書を失効させ、その後、証明書事業からの全面撤退を表明している。当初の指摘を行ったのは、Tekuの監査を担うセキュリティ部門Consensys Diligenceだ。多くの運用者がそのまま展開する事前構築済みのDockerイメージが、双方のケースで影響を受けた配布経路である。Ethereum (ETH)のクライアント群は検証者向けツールをJava上で動かしており、この点が露出と修正の両方の形を決めた。

デフォルトのメインネットノードが安全な理由

両クライアントの実装言語であるJavaは、デフォルトでは証明書が失効済みかを確認しない。そのためTekuのDockerイメージは、ブラウザが証明書を排除した後も侵害された証明書を受け入れ続け、修正がJavaの更新だけではなくイメージの再構築として提供される理由になった。Tekuチームがリリースと合わせて公開した勧告は、攻撃の順序を明示している。検証者と接続先サービスの間に割り込んだ攻撃者はそのサービスになりすませられ、騙された検証者は手数料を攻撃者のアドレスに支払うブロックを提案しかねない。最も危うい構成は検証者の鍵を保有する外部サービスである外部署名者を用いる場合で、偽装された署名者が報酬の送り先を変更する署名を渡してしまう。

Javaのデフォルトのこの隙間が、対応の順序を説明する。ブラウザは失効確認を行うため1日以内に証明書を遮断した。Java上に構築されたEthereumツールはそうでなく、クライアント各チームは実行環境の修復を待たず、eMudhraを信頼済み集合から除いたDockerイメージを再構築した。大多数の運用者への報せは単純だ。デフォルト設定のままメインネットで稼働するTekuのノードは影響を受けず、対応も不要であり、これまでのところ報酬の窃取も確認されていない。対処は構成によって分かれる。事前構築済みDockerイメージを使う運用者は最新のTekuまたはBesuを取得すればよい。一方、ソフトウェアを自らのマシンに直接インストールしている場合は作業が増える。Ethereumクライアントの更新はホスト側のJava環境に触れず、新イメージもホストのJavaを修復しないからだ。最も難しいのは依然Java 26を使うケースで、このバージョンはサポート終了に達しており修正版が提供されないため、Java 25への移行が唯一の出路となる。

総括すれば、今回の件はプロトコルの話というより運用の話だ。コンセンサス層は持ち堪え、実際に露出のあった層は狭い。外部署名者を使う運用者、非デフォルトのネットワーク経路を採る運用者、古いJava環境を抱える運用者である。とはいえ、Ethereumノードの運用に伴う維持管理を検討する者にとっては、クライアントの外側にある実行環境が独自の修正サイクルを必要とする事例として記録に残る項目だ。修正済みの両バージョンは各プロジェクトのリポジトリで既に公開されており、あらゆる運用者が今日から対処できる。2つのリリース以降、脆弱性の深刻度に対する第三者評価は表れておらず、当面はクライアント各チームの勧告が唯一の公開評価となっている。