CVE-2023-26489 in wasmtime
要約
〜によって VulDB • 2026年05月27日
wasmtimeは、高速で安全なWebAssemblyランタイムです。影響を受けるバージョンでは、wasmtimeのコードジェネレーターであるCraneliftに、x86_64ターゲットにおいてバグがあります。このバグにより、アドレスモードの計算が誤って35ビットの有効アドレスを計算してしまい、WebAssemblyで定義されている33ビットの有効アドレスの代わりに計算されてしまいます。このバグにより、デフォルトのコード生成設定では、wasm制御のロード/ストア操作が、線形メモリのベースから最大35ビット離れたアドレスを読み書きできる可能性があります。しかし、このバグのため、ゲストコードからは線形メモリのベースから最大 `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` バイト離れたアドレスへのアクセスが可能になります。つまり、線形メモリのベースから6G先から約34G先までの仮想メモリを、悪意のあるモジュールが読み書きできます。ゲストモジュールは、エンベッダーの知識なしに、この領域のメモリを読み書きできます。例えば、プーリングアロケータを使用している場合、このメモリは他のWebAssemblyインスタンスに属している可能性があります。影響を受けるエンベッダーは、誤ったコード生成ルールによって影響を受けているかどうかを確認するために既存のwasmモジュールを分析し、さらに履歴実行中の異常な数のトラップと相関させることで、疑わしいモジュールを特定することを推奨します。Craneliftのx86_64バックエンドにおける特定の問題は、1から3の定数分だけ左シフトされるWebAssemblyアドレスが、シフト演算を行うx86_64のアドレスモードに折り畳まれてしまうことです。例えば、`(i32.load (i32.shl (local.get 0) (i32.const 3)))` は、WebAssemblyアドレス `$local0 << 3` からロードします。Craneliftに変換されると、32ビット値である `$local0 << 3` の計算は64ビット値にゼロ拡張され、線形メモリのベースアドレスに追加されます。Craneliftは `%base + %local0 << 3` を計算する `movl (%base, %local0, 8), %dst` という形式の命令を生成します。しかし、ここで問題なのは、アドレス計算が64ビット値で行われることです。本来 `$local0 << 3` の計算は32ビット値に切り捨てられるべきでした。これにより、アドレスに最大32ビットを使用できる `%local0` が、この `movl` 命令を通じてアクセス可能なアドレス空間に3ビット追加されてしまいます。Craneliftでの修正は、これらのゼロ拡張式を処理するバックエンド内の誤ったローリングルールを削除することです。上記の例は、`movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` に変換され、これにより `%local0 << 3` の中間計算が `%temp` レジスタ内で正しく32ビットに切り捨てられ、その後 `%base` 値に追加されます。wasmtimeバージョン4.0.1、5.0.1、および6.0.1がリリースされ、誤ったローリングルールを含まないようパッチが当てられています。wasmtimeのアップデートを推奨しますが、アップデートが不可能な場合、エンベッダーはこの問題を緩和するためにいくつかの回避策を採用できます。これらの回避策はデフォルトで有効になっておらず、明示的な設定が必要であることに注意してください。
1. `Config::static_memory_maximum_size(0)` オプションを使用すると、線形メモリへのすべてのアクセスを明示的に境界チェックを行うように強制できます。これにより、アドレスモードの計算とは別に境界チェックが行われ、ロード/ストアの有効アドレスが正しく計算されます。ただし、これによりWebAssemblyモジュールの実行パフォーマンスに大きな影響が出る可能性があります。 2. `Config::static_memory_guard_size(1 << 36)` オプションを使用すると、線形メモリの後に配置されるガードページのサイズを大幅に増やすことができます。これにより、最大34G離れたメモリアクセスが、インスタンスごとに未マップのメモリを予約することで、セマンティックに正しいことが保証されます。ただし、これによりインスタンスごとに非常に大きな量の仮想メモリが予約され、実行可能な同時インスタンスの最大数が大幅に減少する可能性があります。 3. x86_64以外のホストを使用できる場合、このバグを回避できます。このバグはwasmtimeやCraneliftのAArch64バックエンドには影響しません。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.