SandboxJSにおけるサンドボックス脱出の脆弱性(CVSS 10.0)と緊急対応ガイド

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。

SandboxJSにおけるサンドボックス脱出の脆弱性(CVSS 10.0)と緊急対応ガイド

【脅威の概要と背景】

SandboxJSにおいて、プロトタイプ汚染や内部オブジェクトへの不正アクセスによるサンドボックス脱出(RCE)を可能にする4件の脆弱性が判明。CVSS 10.0を記録。

【攻撃シナリオの可視化】

攻撃者は、信頼できないJavaScriptコードを実行環境に注入し、Node.jsの内部プロセス(processオブジェクト)へアクセスすることで、ホストOS上で任意のコマンドを実行します。

graph TD
    A["外部攻撃者"] -->|悪意あるJSコードを送信| B["SandboxJS 実行環境"]
    B -->|脆弱なコンストラクタ参照| C{"サンドボックス境界"}
    C -->|脱出成功| D["ホストOSのprocessオブジェクト"]
    D -->|子プロセス作成| E["任意のOSコマンド実行/RCE"]
    E -->|情報窃取・永続化| F["システム完全侵害"]

【安全な実装と設定】

SandboxJSや類似のライブラリ(vm2等、現在は非推奨のものを含む)を使用する際、単純な実行はホスト環境へのポインタを隠蔽しきれません。

1. 誤用例:脆弱なコード(Sandbox脱出が可能)

攻撃者が constructor を連鎖させることで、グローバルスコープの Function を取得し、OSコマンドを実行できてしまいます。

const Sandbox = require('sandbox');
const s = new Sandbox();

// 攻撃ペイロード例: constructorを辿ってホストのprocessにアクセス
const payload = `
    this.constructor.constructor('return process')().mainModule.require('child_process').execSync('whoami')
`;

s.run(payload, (res) => {
    console.log(res); // ホストの実行結果が出力されてしまう
});

2. 安全な代替案:プロセスの物理分離

Node.js標準の vm モジュールや簡易サンドボックスではなく、より強力な隔離機構を持つ isolated-vm を使用するか、コンテナ(Docker等)レベルでの制限を検討してください。

// isolated-vm を用いたメモリ・実行時間の制限例
const ivm = require('isolated-vm');
const isolate = new ivm.Isolate({ memoryLimit: 128 });
const context = isolate.createContextSync();

const script = isolate.compileScriptSync('1 + 1'); // 信頼できないコード
// ホストのオブジェクトを一切渡さない、あるいは完全にラップして渡す
context.evalSync('1 + 1', { timeout: 100 });

【検出と緩和策】

検出ポイント

  • EDR/SIEM: Node.jsプロセス(node)が、予期しない子プロセス(sh, cmd.exe, curl, whoami 等)を生成していないかを監視。

  • ログ分析: constructor, __proto__, process, mainModule といったキーワードを含む不審な入力の試行を検知。

緩和策(Workaround)

  1. 即時アップデート: 修正パッチが適用された最新バージョンへの更新。

  2. 実行環境の隔離: サンドボックスを実行するプロセス自体を、読み取り専用のファイルシステムおよびネットワーク遮断されたコンテナ内で実行する。

  3. 入力バリデーション: 実行前にAST(抽象構文木)解析を行い、危険なプロパティアクセス(.constructor 等)を拒絶する。

【実務上の落とし穴】

  • パフォーマンスとのトレードオフ: isolated-vm や Docker による隔離は、単純なライブラリ利用に比べてオーバーヘッドが大きく、リアルタイム性が要求されるサービスでは遅延が問題になる可能性があります。

  • いたちごっこ: JSのサンドボックス脱出手法は多岐にわたります。ライブラリだけに依存せず、「脱出されることを前提とした」最小権限(Least Privilege)設計が不可欠です。

【まとめ】

組織として直ちに以下の3点を確認・実施してください。

  1. 資産調査: 自社製品および内部ツールにおいて sandbox (SandboxJS) または vm2 を利用している箇所を特定する。

  2. 即時更新または代替: 修正版へのアップデート、または isolated-vm 等のより堅牢な実装への移行を検討する。

  3. 多層防御の適用: サンドボックス実行プロセスに付与されているOS権限を最小化し、万が一脱出されても被害をコンテナ内に封じ込める設定を確認する。


参考文献:

ライセンス:本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL(本ページ)を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました