Ledgerが公表した内容
Ledgerは8月27日、Security Bulletin 024を公開しました。EthereumアプリのGeneric Transaction Parserは、攻撃者が制御できる配列長を16ビット値として読み取る一方、確認処理のカウントダウンを8ビットのフィールドに保存していました。そのため257要素の配列は1として扱われ、端末には最後の操作だけが表示される一方、EIP-712署名はバッチ全体を承認していました。
Ledgerは本件をHighに分類し、Ethereumアプリ1.19.0から1.22.2が影響を受けるとしています。1.22.3では、値を狭い型へ代入する前に、収まらない要素数を拒否します。既知の悪用はなく、エンドツーエンド検証はプライベートなネットワークフォーク上の単一所有者で実施され、本番フロントエンドの侵害、公開ネットワークへの送信、実資産の移動はなかったと報告されています。
信頼できる表示はデータ表現の境界で破綻した
これは暗号技術の失敗ではありません。署名はトランザクションのバイト列全体を正しく対象とし、受信コントラクトも署名を正しく検証しました。壊れた不変条件は、表現と承認の間にありました。署名対象より少ない操作しか端末が説明せず、型の切り詰めが、有効な要素数を拒否せず別の確認件数へ変換していました。
ウォレットとコントラクトの開発チームは、トランザクション表示をUI上の装飾ではなく、セキュリティ上重要なパース処理として扱うべきです。長さ、インデックス、列挙値、小数変換、ネストしたオフセット、未知フィールドには検査付き変換とフェイルクローズが必要です。テストでは通常取引だけでなく、255、256、257などの境界値や自動生成した敵対的構造を使い、表示した意味オブジェクトとハッシュ化した対象が完全に一致することを確認すべきです。
しきい値署名は自動的に独立した確認にはならない
Ledgerが説明する通り、この脆弱性はマルチシグのしきい値を下げません。攻撃者は同じハッシュに対して必要数の署名を集める必要があります。しかし全所有者が同じ影響対象アプリとディスクリプターを使えば、すべての信頼表示が同じパース誤りを繰り返します。複数の確認は鍵の独立性を提供しても、検証経路の独立性は提供しません。
高額操作では、意図の確認方法を分散すべきです。ある署名者は別実装のデコーダーを使い、別の署名者は人間が読めるトランザクション明細をシミュレーション結果と照合します。署名依頼の前には、バッチ件数、送信先、セレクター、金額、合計上限をポリシー基盤で強制できます。例外的なバッチでは、トランザクションハッシュと想定操作件数を記載した別経路の承認記録を残します。同じコードを動かす端末を増やすことは冗長化であり、多層防御ではありません。
直ちに取るべき運用対応
Ethereum署名にLedgerを使う運用者は、ウォレット管理手順で更新が完了したと推測せず、全署名端末がアプリ1.22.3以降であることを確認すべきです。クリア署名ディスクリプターとバッチ対応コントラクトのエントリーポイントを棚卸しし、パーサー上限付近の配列を検知し、異常に大きいバッチには一時的に独立したデコードまたはシミュレーションを必須にする必要があります。
公表内容によると、悪用には侵害されたホスト、攻撃者制御の255要素超の配列を反復するディスクリプター、その形式を受け入れるコントラクトが必要です。条件は限定的ですが、検知方針には利用できます。過去の署名要求から過大な配列や想定外のバッチ構成を調べつつ、「既知の悪用がないこと」と「特定環境が影響を受けなかった証拠」を分けて扱うべきです。
Ineezaの見解
金融の承認システムには、トランザクション生成、表示、ポリシー評価、署名、実行まで一貫した意味の完全性が必要です。各段階を相互検証可能にすることが持続的な対策です。しきい値は同意に必要な鍵の数を制御しますが、署名者が見たと考えた内容に同意したことを確かめるには、独立したパース、シミュレーション、ポリシー統制が必要です。