はじめに：まさかの「サンドボックス破り」？フロントエンドエンジニアが知るべき深刻な脆弱性

こんにちは、日本のフロントエンドエンジニアの皆さん。今回は、Node.js環境で動作するバリデーター機能を持つライブラリ`@evomap/evolver`に発見された、非常に危険な脆弱性GHSA-jxh8-jh77-xh6gについて解説します。サンドボックス化された環境でさえも、リモートからのコード実行（RCE）が可能となるこの問題は、私たちWeb開発に携わる者にとって決して他人事ではありません。

特に`npm`や`npx`といった、日頃から利用しているツールが悪用される可能性を秘めているため、そのメカニズムと対策をしっかりと理解しておくことが重要です。

脆弱性の概要：なぜ安全であるべきサンドボックスが機能しないのか？

今回問題となっているのは、`@evomap/evolver`のバリデーター機能におけるサンドボックスの設計上の欠陥です。通常、サンドボックスは信頼できないコードを安全に実行するための隔離環境ですが、この実装には複数の重大な問題がありました。

**「問題点1：`npm`と`npx`の実行許可」**

サンドボックスは、安全なJavaScriptコードの実行に使う`node`コマンドだけでなく、`npm`と`npx`コマンドの実行も許可していました。しかし、`npm install`や`npx`は、パッケージのインストール時や実行時に自動的にスクリプト（`preinstall`, `postinstall`など）を実行する特性を持っています。これにより、悪意のあるパッケージやコマンドを介して、任意のコードが実行されてしまう抜け道が生まれていました。

**「問題点2：Hubからのコマンドに対する署名チェックの欠如」**

さらに深刻なのは、バリデーターノードが中央サーバー（Hub）から受け取る検証タスク（`validation_commands`）を、その内容の正当性を示すデジタル署名なしに直接サンドボックスに渡して実行していた点です。本来行われるべきセキュリティポリシーチェックもスキップされていました。

**「問題点3：不十分なサンドボックス隔離」**

現在のサンドボックスは作業ディレクトリや一部の環境変数を制限する程度で、コンテナ化や権限分離といった本格的な隔離は行われていません。そのため、攻撃コードが実行された場合、バリデータープロセスと同じ権限でシステムファイル操作やネットワーク通信が自由にできてしまう状態でした。

攻撃シナリオ：Hubの乗っ取りから全ノードへのRCE自動感染まで

この脆弱性を悪用するには、攻撃者がHubサーバーを乗っ取るか、Hubとバリデーター間の通信を中間者攻撃で傍受する必要があります。その後、以下のような流れで攻撃が実行されます。

**「ステップ1：Hubの乗っ取りと悪意あるタスクの作成」**

攻撃者は、悪意のある`npm install`や`npx`コマンドを含む検証タスクをHubを通じて作成します。

**「ステップ2：署名チェックなしでのコマンド受信」**

バリデーターノードは、Hubからの検証タスクを含む応答を、その署名を検証することなくそのまま受け入れます。

**「ステップ3：セキュリティチェックの回避」**

受け取ったコマンドは、本来行われるべきセキュリティポリシーチェック（`policyCheck.isValidationCommandAllowed()`）をスキップしてサンドボックスに渡されます。

**「ステップ4：危険なコマンドの実行」**

サンドボックスは`npm`や`npx`を許可リストに含んでいるため、悪意のある`npm install`や`npx`コマンドを「合法的なもの」と判断して実行してしまいます。

**「ステップ5：任意のコード実行と広範囲な感染」**

`npm`や`npx`の特性を利用して、インストールスクリプトやバイナリを介して攻撃者の用意した任意のコードがバリデーターノード上で実行されます。`v1.69.0`以降のバージョンではバリデーターモードがデフォルトで有効なため、Hubが攻撃されると、デフォルトで約60秒ごとにポーリングしているすべてのバリデーターノードが自動的に攻撃されてしまいます。これはネットワーク全体への壊滅的な感染を意味します。

想定される影響：あなたのPCも「乗っ取り」の危機に？

この脆弱性が悪用された場合、非常に深刻な影響が考えられます。

**「任意のコード実行（RCE）」**

バリデータープロセスと同じユーザー権限で、ホストシステム上で任意のコードが実行されます。これは、攻撃者があなたのPCを完全に制御できることを意味します。

**「機密情報の漏洩」**

APIキー、認証情報、設定ファイルなど、バリデータープロセスがアクセスできる機密情報が盗まれる可能性があります。あなたのAWS認証情報やGitHubトークンなども危険に晒されるかもしれません。

**「システム乗っ取りと永続化」**

システム設定の変更、マルウェアのインストール、他のシステムへの攻撃の足がかり（水平展開）として利用される恐れがあります。一度侵入されると、永続的なバックドアを仕掛けられる可能性もあります。

**「ネットワークを介した感染拡大」**

Hubの乗っ取り1つで、ネットワーク上のすべてのバリデーターノードへの自動的なRCEに繋がるため、広範囲にわたる被害が発生し、連鎖的にシステムが侵害されるリスクがあります。

**「サンドボックス保証の破綻」**

本来、信頼できないコードを安全に実行するためのサンドボックス機能が、その目的を全く果たせなくなります。

今すぐ取るべき対策：あなたのシステムを守るために

この重大な脆弱性からシステムを守るため、以下の対策を最優先で実施してください。

**「対策1：`npm`と`npx`の実行許可リストからの削除（最重要）」**

最も直接的かつ効果的な対策は、`src/gep/validator/sandboxExecutor.js`内の`ALLOWED_EXECUTABLES`セットから`npm`と`npx`を削除し、`node`コマンドのみを許可することです。バリデーションタスクに`npm`や`npx`が必須ではない限り、これらを削除することが強く推奨されます。

**「対策2：Hubレスポンスの署名と検証の導入」**

Hubからバリデーターに送られる検証タスクを含むレスポンスにデジタル署名を付与し、バリデーター側でその署名を厳密に検証するようにシステムを改修します。これにより、Hubが中間者攻撃を受けても、改ざんされた不正なタスクが実行されるのを防ぐことができます。

**「対策3：より強力なサンドボックス隔離の導入」**

現在のサンドボックス環境を強化し、権限降下（より低い権限でプロセスを実行）、ネットワークアクセス無効化、一時的なファイルシステム（tmpfs）の使用、システムコール制限（seccomp）など、OSレベルでのより厳格な隔離メカニズムを導入することを検討してください。Dockerなどのコンテナ技術も有効な手段となり得ます。

**「対策4：セキュリティポリシーチェックの適用」**

Hubから受け取った`validation_commands`に対しても、必ず`policyCheck.isValidationCommandAllowed()`を適用し、不適切なコマンドがサンドボックスに渡されるのを防ぐべきです。これにより、コマンドが実行される前にその内容がセキュリティポリシーに準拠しているかを確認できます。

まとめ：セキュリティは「もしも」ではなく「いつか」

今回の`@evomap/evolver`の脆弱性は、開発者が日常的に使う`npm`や`npx`が、誤ったサンドボックス設計と組み合わせることで、いかに危険なツールになりうるかを示しています。

フロントエンドエンジニアの皆さんにとって、直接`@evomap/evolver`を使用していないとしても、Node.js環境におけるプロセス実行やサンドボックス化の重要性を再認識する良い機会となるでしょう。依存関係の脆弱性スキャンや、セキュアなコーディングプラクティスの徹底を改めて心がけ、安心・安全な開発環境を構築していきましょう。