- V8 サンドボックスは、V8 エンジン向けの軽量なインプロセス・サンドボックス
- すでに実験段階を脱し、Chrome の脆弱性報奨金プログラム(VRP)に含まれている
- なお、まだ解決すべきセキュリティ問題は残っており、Chrome 123 はサンドボックスの「ベータ」リリースと見なせる
動機
- メモリ安全性は依然として重要な問題であり、過去 3 年間に発見されたすべての Chrome エクスプロイトは、V8 のメモリ破損脆弱性から始まっている
- これらの脆弱性のうち 60% は V8 で発生したが、その大半は「典型的な」メモリ破損バグではなく、微妙なロジック上の問題である
- 現在のメモリ安全性ソリューションの多くは V8 に適用できず、Rust のようなメモリ安全言語への移行や、メモリタグ付けのようなハードウェア機能も、V8 のセキュリティ上の課題の助けにはならない
V8(ヒープ)サンドボックス
- サンドボックスの基本的なアイデアは、V8 のヒープメモリを隔離し、メモリ破損がプロセスの他の部分へ「拡散」しないようにすること
- ハードウェア支援によって実装することも可能だが、現時点では適切なハードウェア機能がないため、ソフトウェアベースで実装されている
- サンドボックスは、すべての外部メモリにアクセス可能なデータ型を「サンドボックス互換」の代替に置き換える
- サンドボックス内部にあるのは V8 ヒープのみで、これは WebAssembly のサンドボックスモデルに似ている
性能
- このサンドボックス方式の主な利点は、基本的にコストが低いこと
- サンドボックスによるオーバーヘッドは主に外部オブジェクトへのポインタテーブル間接参照から生じており、現在のオーバーヘッドは一般的なワークロードで 1% 未満
テスト
- セキュリティ境界に対するテスト可能性とは、セキュリティ保証が実際に維持されているかを手動および自動で検証できる能力を意味する
- V8 サンドボックスは、明確な攻撃者モデル、攻撃者を模倣する方法、そしてセキュリティ境界が破られたときに自動で判定する方法のすべてを満たしている
利用
- V8 サンドボックスは、ビルド時に
v8_enable_sandbox ビルドフラグを使って有効化または無効化する必要がある。
- 利用できるのは 64 ビットシステムのみで、現在は 1 テラバイトの仮想アドレス空間を予約する必要がある。
- V8 サンドボックスは、すでに約 2 年前から Android、ChromeOS、Linux、macOS、Windows の 64 ビット版 Chrome でデフォルトで有効になっている。
結論
- V8 サンドボックスは、プロセス内の他のメモリに影響を及ぼす V8 のメモリ破損を防ぐために設計された新しいセキュリティメカニズム
- 現在のメモリ安全技術の多くは最適化された JavaScript エンジンには適用しづらいが、V8 サンドボックスの攻撃面を保護するうえでは効果的である
- サンドボックスは、メモリ安全性に向けた不可欠なステップである
GN⁺の見解
- V8 サンドボックスは、メモリ破損脆弱性に対する現代的な対策であり、既存のメモリ安全技術では解決できない問題への答えを提示している
- このサンドボックスは、JavaScript エンジンの複雑さを考えると、セキュリティ境界をさらに強化し、メモリ安全性を向上させる重要な役割を果たす
- サンドボックスの性能オーバーヘッドが低い点は開発者にとって魅力的であり、広範な採用を後押しするだろう
- ただし、サンドボックス技術がまったく新しいセキュリティ脆弱性を持ち込む可能性もあり、これは継続的な監視とテストによって管理されるべきである
- サンドボックスの効果的な実装は、攻撃者によるメモリ破損のシステムの他部分への拡散防止に重要な役割を果たし、Web セキュリティの強化に寄与するだろう
まだコメントはありません。