以太坊節點安全修補：二進位安裝版須檢查 Java

以太坊(ETH)節點客戶端 Teku 與 Besu 已調整 Docker 映像檔的信任清單，以因應 eMudhra 憑證機構事故；使用執行檔安裝的營運者則須檢查 Java 執行環境的憑證儲存庫。

Teku 團隊於 27 日發布包含安全修補的 26.10.3 版，並建議使用者更新。Besu 也在 26.10.2 版修改相關信任清單，但這項修補僅適用於 Docker 映像檔。

兩項更新都移除了對 emSign ECC Root CA - G3、emSign Root CA - G1、emSign Root CA - G2 與 AAA Certificate Services 的信任。Besu 團隊表示，移除 G1 是預防措施。

這次處置源於 eMudhra 建立的中繼憑證機構私鑰可從公開憑證還原。使用該金鑰簽署的憑證，在尚未修補的 Java 執行環境中可能被視為有效憑證接受。

eMudhra 於 26 日聲明，腳本錯誤導致系統建立了使用弱金鑰的中繼憑證機構。公司表示，發現問題後 14 小時內便撤銷該憑證機構；調查結果也顯示，公司基礎設施與客戶資料未遭入侵。

Mozilla 事故紀錄中，一名參與者記載，從韓國時間 20 日下午 6 時 40 分至 22 日上午 7 時 2 分，共有 10萬7107 張由問題金鑰簽署的憑證出現在 e-Szignó 記錄中。其中 10萬6050 張是單一網域的概念驗證憑證。

eMudhra 表示，該公司沒有透過問題中繼憑證機構簽發受公開信任的終端使用者憑證。Mozilla 紀錄則包含其他主體使用問題金鑰簽署的憑證，因此兩者不能視為同一筆統計；紀錄中的憑證也不代表曾被用於實際攻擊。

憑證用於 HTTPS 連線，確認對端伺服器的身分。Java 預設不會檢查憑證是否已撤銷，因此只要相關根憑證機構仍留在信任儲存庫中，單靠撤銷憑證未必能阻止連線。

Teku 團隊表示，未在設定中填入 HTTPS 位址的預設主網節點不受影響。判斷風險時，應檢查實際連線設定，而非只看節點客戶端名稱。

若節點透過 HTTPS 連接外部簽署者、遠端信標節點、執行客戶端或建構者，且使用尚未修補的 Java 執行環境，就可能面臨風險。即使如此，攻擊者仍須能攔截通訊，才能冒充對端伺服器。

不使用憑證機構的節點間 P2P 通訊不在此次問題範圍內。因此，Teku 團隊指出的影響限於依賴憑證信任的 HTTPS 連線，並非所有節點連線。

Besu 另有一項設定需要檢查。啟用 --rpc-http-tls-ca-clients-enabled 後，Besu 會接受由 Java 預設信任儲存庫中的憑證機構簽署的用戶端憑證；Besu 團隊將這項設定列為高風險。

若啟用該設定，攻擊者只要能連上 RPC 連接埠，就可能觸發問題，不必攔截通訊。使用 Besu 預設設定的節點不受影響；Besu 團隊也表示，目前沒有接獲實際遭利用的案例。

Docker 映像檔內含獨立的 Java 執行環境，因此修改主機電腦上的 Java 不會改變容器內的執行環境。Teku 執行檔與 Besu 的 tar、zip 發行套件則使用營運者安裝的 Java；營運者應分別確認安裝方式、實際執行環境的憑證儲存庫，以及 HTTPS 與 TLS 設定。