広く使われているNode.jsサンドボックスライブラリ「isolated-vm」に、重大な脆弱性が発見されました。この欠陥により、信頼できないJavaScriptがV8アイソレートから脱出し、ホストプロセスの制御フローを乗っ取れる可能性があります。
TryingCybersecurity And Penetration Testing Tools
この問題はGHSA-864f-rcv7-6rh4として追跡されており、CVE番号の割り当てを待っている状態です。影響を受けるのはisolated-vmのバージョン7.0.1および6.2.0より前のものです。
研究者らは、ホストがサンドボックス化されたコードに限定的な機能を公開する際に一般的に使用される単一のivm.Referenceへのアクセス権を持つ攻撃者が、ホストプロセスのメモリ破損を引き起こし、確実なサービス拒否(DoS)を発生させ、制御フロー乗っ取りへの経路を作り出せることを実証しました。
ExternalCopyにおける型混同
この脆弱性の根本原因は、V8アイソレート間でデータを転送するisolated-vmのExternalCopyメカニズムにあります。V8アイソレートは独立したヒープを持ち、オブジェクトグラフを共有しないため、ゲストとホストの境界を越える際には値をシリアライズして再構築する必要があります。
ExternalCopyはtransferListオプションをサポートしており、これによりArrayBufferを基盤となるメモリをコピーせずに転送できます。しかし研究者らは、このライブラリが指定された転送リストを2回処理していることを発見しました。
1回目の反復処理では、isolated-vmは各項目がArrayBufferであることを検証します。2回目の反復処理では、検証チェックを繰り返さずに各項目を転送します。
この脆弱なコードはチェックなしのAs<ArrayBuffer>()変換を実行しており、事実上、2回目の読み取りが以前に検証されたものと同じオブジェクトを返すことを信頼してしまっています。
この前提は、攻撃者がJavaScriptのゲッターを指定した場合に破綻します。配列要素の読み取りはユーザー制御下のアクセサを呼び出せるため、ゲッターは検証時には正規のArrayBufferを返しつつ、2回目のパスでは別の値を返すことができます。
let reads = 0;
Object.defineProperty(transferList, 0, {
enumerable: true,
get() {
return ++reads === 1 ? real : 0x41414141;
}
});これはTOCTOU(time-of-check/time-of-use)脆弱性を生み出します。チェックされていない値がネイティブC++コードによってArrayBufferとして扱われ、攻撃者が制御可能なメモリの参照外しにつながります。
研究者らは、サンドボックス化されたゲストが公開された1つのivm.Referenceだけを使って、脆弱なExternalCopyコンストラクタにアクセスできることを実証しました。これはReferenceがホスト側の機能への制御されたアクセスを提供するために一般的に使われているため、重要な意味を持ちます。
概念実証(PoC)では、攻撃者が制御するアドレスを使用した際に、v8::ArrayBuffer::IsDetachable内でホストプロセスがSIGSEGVでクラッシュすることが示されました。この制御されたクラッシュだけでもサービス拒否攻撃が可能ですが、研究チームはさらにこの欠陥を深刻化させました。
JavaScriptの文字列を混同対象のオブジェクトとして使用することで、攻撃者はネイティブオブジェクトのフィールドとして解釈されるバイトを操作できます。欠陥のある転送のクリーンアップ処理は最終的にvtableポインタを介した間接呼び出しを実行するため、制御フロー乗っ取りのプリミティブが生まれます。
EndorLabsの研究者らは、完全なエクスプロイトの詳細は非公開としているものの、選択したlibc関数へのホスト実行のリダイレクトを実証したと報告しています。
isolated-vmライブラリは、自動化ツール、AIエージェント、ローコードプラットフォーム、マルチテナントのスクリプト実行環境など、ユーザーやモデルが生成したJavaScriptを実行するシステムで使用されています。研究者らが特定したプロジェクトには、n8n、Activepieces、Mastra AI、Budibase、Sim.ai、Directus、Rocket.Chatが含まれます。
重要なのは、この脆弱性がV8アイソレートのセキュリティモデル自体を侵害するものではないという点です。むしろ、境界を越えたデータのマーシャリングを担うC++バインディング層を弱体化させるものであり、安全でないネイティブグルーコードが本来堅牢な分離プリミティブをいかに弱めうるかを示す事例です。
メンテナーはisolated-vmのバージョン7.0.1および6.2.0で修正版をリリースしました。このパッチでは、コピー操作中にv8::Isolate::DisallowJavascriptExecutionScopeを実装しており、ExternalCopyが機密データを処理している間、ゲッターやプロキシ、その他のJavaScriptコールバックが実行されないようにしています。
isolated-vmを使用している組織は、直ちにアップグレードを行うとともに、信頼できないコードと共有するReferenceの数を最小限に抑え、攻撃者が制御するデータがExternalCopyやtransferListの処理に影響を及ぼしていないか監査することが推奨されます。
ImplementingEnterprise Data Storage Solutions
調査の遅れによるインシデントを防ぎましょう。15,000のSOCからの脅威インテリジェンスでTier 1を強化: TI LookupをSOCに統合する
翻訳元: https://gbhackers.com/critical-isolated-vm-flaw/
