Memory Corruption in WebAssembly: Native Exploits Inside You

はじめに：ネイティブコードとウェブの接点

WebAssembly (WASM) は、ブラウザでほぼネイティブと同等のパフォーマンスを実現し、ウェブ開発に革新をもたらしました。開発者は今や C、C++、Rust などの言語をポータブルなバイナリ形式にコンパイルし、驚くほど高速に実行させることが可能です。しかし、この技術的飛躍は、意図せずしてセキュリティ上の課題の扉を開けてしまい、ネイティブプラットフォームからの古典的なメモリ破損の脆弱性をブラウザ環境に持ち込んでいます。

WebAssemblyの約束は魅力的です：パフォーマンス重視のアプリケーションをプラグインやネイティブインストールなしでウェブブラウザ上でシームレスに動作させること。しかし、その裏には現実もあります。従来のメモリ安全性の脆弱性、バッファオーバーフローや use-after-free などがWebAssemblyモジュール内で依然として存在し、新たなブラウザの脆弱性のフロンティアを形成しています。

WebAssemblyのメモリモデルの理解

リニアメモリ：両刃の剣

WebAssemblyのリニアメモリモデルは、単一の連続したアドレス空間を用いてメモリを管理します。これにより、処理ユニットはメモリ位置に直接、逐次的にアクセス可能です。この設計は高いパフォーマンスを提供しますが、一方でモジュールが割り当てられた範囲外のメモリにアクセスした場合に重大なセキュリティリスクをもたらします。

JavaScriptの管理されたメモリ環境とは異なり、WebAssemblyは低レベルのメモリ割り当てと操作を開発者に許しています。C/C++の変数は、WebAssemblyでは二つのプリミティブに低レベル化されます：固定スコープのローカル変数（インデックス空間に格納）と、静的スコープが不明なローカル変数（リニアメモリのスタックに格納）。この設計は、古典的なメモリ破損の脆弱性を引き起こす可能性を孕んでいます。

コンパイラのギャップ：セキュリティ保護の欠如

最近の研究では、WebAssemblyのコンパイルにおける重大なセキュリティのギャップが明らかになっています。CプログラムをWASMにコンパイルした場合、ネイティブアーキテクチャで標準的に備わるスタックカナリアなどの防御策が欠如していることが判明しています。コンパイラ（例：Clang）でx86向けに生成されたコードと比較して、WebAssemblyではセキュリティ対策が不十分なため、脆弱性が残るケースがあります。

4690の既知のバッファオーバーフロー脆弱性を持つCプログラムをx86とWebAssemblyにそれぞれコンパイルしたところ、結果が異なるケースがありました。WebAssemblyではスタックカナリアなどのセキュリティ対策が欠如しているため、スタックベースのバッファオーバーフローでクラッシュせずに動作を続けることもあります。

この事実は、WebAssemblyに対するセキュリティの前提を根底から覆すものであり、スタック破壊保護がなければ、攻撃者の制御下で動き続ける可能性があることを示しています。一方、ネイティブコードはクラッシュして安全を保ちます。

WebAssemblyにおけるバッファオーバーフロー：古典的脅威と新環境

WASMでのバッファオーバーフローの現れ方

バッファオーバーフローは、インデックス空間に格納されたローカルやグローバル変数には影響しません（これらは固定サイズでインデックスでアドレスされるため）が、リニアメモリに格納されたデータは隣接するオブジェクトを上書きする可能性があります。境界チェックはリニアメモリの領域単位で行われ、コンテキストに依存しません。

特定の状況下では、strcpyのような危険な関数を用いることで、メモリ上に連続して格納されたローカル変数を攻撃者が上書きできる場合があります。この古典的なバッファオーバーフローのシナリオは、WebAssembly環境に直接翻訳され、攻撃者が隣接するメモリ領域を破壊できるようになります。

スタックベースの破壊攻撃

WebAssemblyのバイナリは、多くの場合、バッファオーバーフローやメモリ破損の後も実行を続けます。これは、WebAssemblyバイナリにStack Smashing Protection (SSP)が存在しないためです。これにより、攻撃者はステルス的にバッファオーバーフローを悪用できるため、ネイティブよりも脆弱性が高まります。

ネイティブアプリケーションでバッファオーバーフロー検知に使われるスタックカナリアは、多くのWASMバイナリには見られません。これは、WebAssemblyのサンドボックスが十分な保護を提供すると想定された結果ですが、研究によりその前提は誤りであることが示されています。

ヒープメタデータの破壊

研究では、emmallocアロケータを用いたWebAssemblyの高度なヒープエクスプロイト技術も示されています。ヒープのメタデータの破壊攻撃では、一つの割り当てのオーバーフローが隣接するメタデータを書き換え、使用済みビットを操作し、次の解放操作時に偽の構造体を作り出します。

これらの攻撃は、ネイティブプラットフォームの古典的なヒープエクスプロイト技術を模倣しており、WebAssemblyのサンドボックスはメモリ破損の根本的なリスクを排除していないことを示しています。単にブラウザ環境内に移動しただけです。

use-after-free（UAF）脆弱性：継続する危険性

つきまとうダングリングポインタ

use-after-free（UAF）脆弱性は、解放されたメモリをプログラムが引き続き使用する場合に発生します。メモリ安全性のないCコードは、Wasmにコンパイルされても安全ではなく、攻撃者はバッファオーバーフローや use-after-free をネイティブとほぼ同じように悪用できます。

最近のWebAssemblyツールの脆弱性には、wabtツールキットのGetFuncOffset関数に関するCVE事例などがあります。これらは、C/C++からWebAssemblyへのコンパイル過程で、ダングリングポインタのバグが残存していることを示しています。

悪用の難しさと可能性

WebAssemblyにおけるuse-after-freeの脆弱性は、攻撃の難易度と可能性の両面で特有の課題をもたらします。従来のメモリ破損対策が欠如しているため、一度UAF状態に陥ると、攻撃者にとっては比較的容易に悪用できる可能性があります。

ただし、WebAssemblyのサンドボックス実行モデルや制御フローの整合性機能により、従来のリターン・オリエンテッド・プログラミング（ROP）ガジェットの直接挿入やコード実行は制約されます。

コントロールフローの乗っ取り：間接呼び出しの脆弱性

関数ポインタの悪用

制限されたコントロールフローの乗っ取りは、WebAssemblyのcall_indirect命令を悪用することで可能です。これは、コンパイラが静的に呼び出す関数を特定できない場合に、関数ポインタをサポートするための仕組みです（例：コールバック関数や動的メソッド）。この仕組みは、WebAssemblyの暗黙のコントロールフロー整合性を弱める可能性があります。

関数ポインタがリニアメモリに格納された変数にコンパイルされている場合、攻撃者はバッファオーバーフローを通じてこれらのポインタを書き換え、プログラムの実行フローを制御できます。WebAssemblyのコントロールフロー整合性は、呼び出しターゲットがロード時に宣言された有効な関数でなければならないことを保証しますが、それでも攻撃者にとっては制御可能なターゲットの一部を提供します。

クロスサイトスクリプティング（XSS）の増幅

WebAssemblyのバッファオーバーフローは、破損したデータが後にDOM操作に使われることで、クロスサイトスクリプティング（XSS）の脆弱性につながることがあります。これは、低レベルのメモリ破損バグが高レベルのウェブアプリケーション攻撃に橋渡しされる例です。

攻撃者は、WebAssemblyモジュールのメモリ破損を悪用し、悪意のあるスクリプトを注入したり、セキュリティポリシーを回避したり、機密データを漏洩させたりすることが可能です。これらは、ブラウザのサンドボックスの安全性の範囲内で行われます。

実世界の脆弱性と攻撃シナリオ

Wasm爆弾とサービス拒否（DoS）攻撃

2023年後半から2024年にかけてのCWA-2023-004は、特定のWebAssemblyコントラクトをアップロードさせる脆弱性です。これらは見た目は小さくとも、読み込み時にメモリを大きく膨張させ、ノードのクラッシュやチェーンの停止を引き起こす可能性があります。

これらの「Wasm爆弾」は、WebAssemblyのコンパイルと実行時の挙動を悪用したDoS攻撃の一例です。

サンドボックス脱出の試み

CVE-2023-51661は、Wasmerランタイムの脆弱性で、コントラクトがサンドボックスのセキュリティ制限を回避し、ノードのファイルシステムに不正アクセスできる例です。これは、WebAssemblyの基本的な隔離保証を破る最も深刻な脆弱性の一つです。

Googleの対応：V8サンドボックスとWASM脅威

新たな防御層

WebAssemblyのメモリ破損に対処するため、GoogleはChromeのV8 Sandboxのサポートを発表しました。これは、V8内のメモリ破損がホストプロセス内に拡散するのを防ぐためのもので、軽量なインプロセスサンドボックスです。これにより、一般的なV8やWebAssemblyの脆弱性に対する防御を強化しています。

V8サンドボックスは、メモリ破損の被害範囲を限定するための重要なアーキテクチャ投資です。すべてのメモリ安全バグを排除するのは不可能に近いため、Googleは被害拡大を抑えることに重点を置いています。

制限と課題

ただし、V8サンドボックスはすべてのWebAssemblyのセキュリティ問題を解決できるわけではありません。WebAssemblyモジュール内のメモリ破損は、アプリケーションのロジックを破壊したり、データを盗んだり、クロスサイトスクリプティング攻撃を可能にしたりします。サンドボックスからの脱出は防げません。

また、サンドボックスはパフォーマンスのオーバーヘッドや実装の複雑さも伴います。セキュリティとWebAssemblyの高いパフォーマンスの両立は、引き続きブラウザベンダやWebAssemblyコミュニティの課題です。

検出と解析の課題

静的解析の限界

従来のセキュリティツールや技術は、WebAssemblyコードの特異な構造と実行モデルのために、脆弱性の検出に効果的でない場合があります。WASMのバイナリは、スタックベースの仮想マシンアーキテクチャと相まって、従来のセキュリティスキャナには盲点を作ります。

静的解析ツールは、ネイティブコード向けに設計されたものは、WebAssemblyのメモリ操作や制御フロー、関数呼び出しの低レベルな意味を理解できません。同様に、JavaScript向けのツールも、WASMモジュールの低レベルの動作やJavaScript環境との連携を理解できません。

専門ツールの必要性

WebAssemblyの脆弱性を検出するためには、静的解析ツールを用いて潜在的なセキュリティ問題を分析し、一般的なメモリ破損エラーのチェックを行う必要があります。ただし、WASM特有のセキュリティツールの開発は、現在も研究の最前線です。

近年の学術研究では、WebAssemblyの特性に合わせた解析器やシンボリック実行エンジン、ファジングフレームワークの開発が進められています。これらのツールは、WASMアプリケーションのセキュリティ可視性向上に寄与しています。

緩和策とベストプラクティス

言語選択によるメモリ安全性

最も効果的な脆弱性緩和策は、メモリ安全な言語を使用することです。WebAssemblyのコントラクトには、Rustのような安全な言語の構造を活用することが推奨されます。Rustは、所有権システムや借用チェッカーによって、メモリ安全性の問題をコンパイル時に排除します。C/C++からのコンパイルよりも安全性が高まります。

Go（WASM実装に制約あり）、Swift、そして最新のC++の厳格なコーディング標準も、脆弱性の表面積を大きく減らすことが可能です。

セキュアなコーディング実践

C/C++とWebAssemblyを扱う場合、開発者は境界チェックを徹底し、メモリ範囲外アクセスを防ぐ必要があります。unsafeな関数の使用を避け、アドレス空間配置ランダム化（ASLR）やデータ実行防止（DEP）などのメモリ保護機構を導入しましょう。

また、C言語のセキュリティ問題は、ネイティブと同様に扱うべきです。emscripten_run_scriptのような動的JavaScript実行は危険です。ClangのControl Flow Integrity (-fsanitize=cfi)フラグを有効にし、最適化を行うことで、エクスプロイトに利用される関数の除去も検討してください。

入力検証とサニタイズ

入力データの検証とサニタイズは、セキュリティリスクを低減させる基本です。JavaScriptとWASM間のデータのやり取りには特に注意し、型の混乱やバッファオーバーフローを防ぐために、悪意のある入力を排除しましょう。

サンドボックスとアイソレーション

WebAssemblyモジュールの能力を制限し、機密データやシステムリソースへのアクセスを防ぐ堅牢なサンドボックスの実装が重要です。モジュール間の隔離とアクセス制御を徹底し、サンドボックス脱出のリスクを抑えましょう。

この多層防御のアプローチは、脆弱性が存在する前提で、その影響を最小化することを目的としています。WebAssemblyモジュールを分離し、システムリソースへのアクセスを制限することで、潜在的な侵害を封じ込めることが可能です。

WebAssemblyセキュリティの未来

メモリ安全なWebAssembly提案

Memory-Safe WebAssembly (MSWasm) は、言語レベルでメモリ安全性を確保する抽象化を導入し、メモリ破損問題に対処しようとしています。型付けされたMSWasmプログラムは、安全性を保証される設計です。これは、WebAssemblyの根本的なメモリ安全性の課題に対する長期的な解決策となる可能性があります。

MSWasmは、コンパイル時にメモリ操作の高レベルな意味情報を保持し、ランタイムでの安全性確保を可能にします。ただし、採用にはWebAssemblyエコシステム全体の調整とパフォーマンスのトレードオフが伴います。

コンパイラとツールチェーンの改善

収集されたバイナリの約80%はLLVMツールチェーンでコンパイルされています。LLVMにStack Smashing Protectionなどのセキュリティ機能を導入すれば、多くのWebAssemblyプログラムに対して追加の保護をもたらすことができ、エンジニアリングコストも抑えられます。これが、WASMのセキュリティ向上の現実的な道です。

コンパイラ開発者は、スタックカナリアや制御フローガード、アドレスサニタイザなどの伝統的なセキュリティ機能をWebAssembly向けに実装する努力を続けています。これらの保護が成熟すれば、ネイティブとWASMのバイナリ間のセキュリティギャップは縮小されるでしょう。

ランタイム防御と監視

ブラウザベンダは、WebAssemblyの悪用に対抗するためのランタイム防御を継続的に進化させています。GoogleのV8 Sandboxに加え、以下のようなアプローチもあります：

メモリの細粒度な区画化
ハードウェア支援のメモリタグ付け
疑わしいWASM動作のランタイム監視
JITコンパイラの堅牢化
コントロールフロー整合性の強化

これらの多層防御は、単一の対策だけではリスクを完全に排除できないことを認識し、総合的なセキュリティ戦略が必要です。

WebAssemblyアプリケーションのセキュリティテスト

ファジングとシンボリック実行

自動化されたテスト手法であるファジングやシンボリック実行は、WebAssemblyモジュールの脆弱性発見に有効です。これらのアプローチは、プログラムの状態や入力空間を体系的に探索し、攻撃者よりも先にメモリ破損バグを特定します。

WAFL（WebAssembly Fuzzing with Fast Snapshots）やSeeWasm（WebAssemblyのシンボリック実行）などの専門ツールは、汎用のテストフレームワークと比べてWASM特有の脆弱性検出能力を向上させています。

セキュリティコードレビュー

WebAssemblyは、ソースコードからの脆弱性を継承する可能性があるため、C/C++コードの徹底的なセキュリティレビューが不可欠です。研究では、C/C++からコンパイルされたWebAssemblyが、ソースコード内の脆弱性を引き継ぎ、悪用可能になるケースも確認されています。

コードレビューのポイントは以下の通りです： - メモリ割り当てと解放のパターン - バッファの取り扱いと境界チェック - ポインタの算術演算とデリファレンス - 整数オーバーフローの可能性 - unsafeなC標準ライブラリ関数の使用

継続的なセキュリティ監視

WebAssemblyアプリケーションを展開する組織は、継続的なセキュリティ監視を実施し、攻撃の兆候を検知すべきです。具体的には：

異常なWASMモジュール動作の検知
メモリアクセスパターンの分析
Wasm爆弾の兆候に対するパフォーマンス監視
Webアプリケーションファイアウォールとの連携
定期的なWASMモジュールのセキュリティスキャン

まとめ：WebAssemblyセキュリティの展望

WebAssemblyは、ウェブアプリケーションに前例のないパフォーマンスをもたらす革新的な技術です。しかし、そのパフォーマンスは、古典的なメモリ破損の脆弱性の再導入というセキュリティコストも伴います。

WebAssemblyが直面するセキュリティ課題は、克服不可能なものではなく、また予期されたものでもありません。パフォーマンス、既存コードとの互換性、セキュリティのトレードオフを反映しています。エコシステムの成熟とともに、検出ツール、ランタイム防御、セキュアな開発実践の進展が見られます。

開発者は、警戒心を持ち、多層的なセキュリティ思考を採用する必要があります。メモリ安全な言語の選択、C/C++の安全なコーディング、コンパイラの保護機能の活用、堅牢なサンドボックスの実装、徹底したセキュリティテストが、より安全なWebAssemblyアプリケーションの構築に寄与します。

WebAssemblyコミュニティにとっては、メモリ安全拡張、ツールチェーンのセキュリティ機能の向上、ランタイム防御の強化が、WASMの潜在能力を最大限に引き出しつつ、ユーザの安全を守るために不可欠です。

ネイティブのエクスプロイトがブラウザに登場した今、対策のためのツール、知識、コミュニティの取り組みも進んでいます。これらのリスクを理解し、包括的なセキュリティ対策を講じることで、WebAssemblyの力を活用しつつ、メモリ破損攻撃からユーザを守ることが可能です。

キーワード：WebAssemblyセキュリティ、WASM脆弱性、バッファオーバーフロー、use-after-free、メモリ破損、ブラウザエクスプロイト、WebAssemblyの脅威、ネイティブコードの安全性、ヒープ破損、スタックオーバーフロー、コントロールフロー乗っ取り、V8サンドボックス、メモリ安全性、WebAssembly緩和策、安全なコーディング