Vm2: while(1){}에 면역되지 않음

이에 대한 좋은 해결책은 없을 것입니다. NodeJS는 단일 프로세스입니다. while (1) {} 보호에는 검사기가 while (1) {}에 의해 차단되지 않도록 다중 프로세스가 필요합니다. 스파이더노드 프로젝트에 다시 불을 붙일 수 있다면.......

이것은에 의해 발생 Decontextify.value 로 게스트 객체의 프로토 타입을 테스트 instanceOf . Node.js vm 모듈은 물론 이것에 영향을받지 않습니다. 가난한 사람의 패치는 Proxy 를 백도어하여 샌드박스에서 프록시 개체를 감지할 수 있도록 하는 것일 수 있지만 이상적인 접근 방식은 샌드박스에서 개체와 기능을 절대 신뢰하지 않고 contextify.js를 샌드박스에 넣는 것입니다. 기본 값을 사용하여 통신하고 게스트 개체 참조를 처리합니다.

사람들이 볼 수 있도록 브라우저리스는 자식 프로세스와 메시지 전달을 사용하여 신뢰할 수 없는 코드를 실행하는 자식과 대화합니다. 약간의 설정 작업이지만 일단 완료되면 while(1){} 공격에 면역이됩니다. 출처는 여기 입니다.

이 프로젝트의 요점은 전체를 별도로 생성하지 않는 것 같습니다.
OS 프로세스. 그렇지 않으면 많은 솔루션을 사용할 수 있습니다.
더 안전합니다.

그렇지 않으면 훨씬 더 안전한 많은 솔루션을 사용할 수 있습니다.

어느 것? NodeJS에서 VM2에 대한 더 나은 대안이 있는지 확실하지 않습니다. 적어도 제가 본 것은 아닙니다.

이 라이브러리의 관리자는 문제 #80에서 이 대안을 지적했습니다.

https://github.com/laverdet/isolated-vm

나는 아직 그것을 스스로 시도하지 않았다.

자식 프로세스에서 신뢰할 수 없는 코드만 실행합니다. 특히 단일 스레드라는 것을 알고 있는 경우 기본 V8 인스턴스에서 실행할 위험이 없습니다.

V8 엔진을 직접 호출하는 문제는 import 모듈이 없다는 것입니다. 제 경우에는 HTTP 작업을 허용하기 위해 요청 모듈을 가져와야 합니다. 또한 비동기식이어야 합니다.

나는 vm2 + child_process가 좋은 조합이라고 생각합니다.

야,

저와 @harelmo 는 while(1) {} 면역이 있는 vm2 위에 라이브러리를 만들었습니다.

tian-ma가 언급한 것과 유사하지만 자식 프로세스 대신 node.js 작업자 스레드를 사용합니다.

https://www.npmjs.com/package/isolated-runtime을 살펴보고 여러분의 생각을 알려주세요 :)

또 다른 해결 방법은 샌드 박스 내에서 Proxy 비활성화하는 것입니다.

const vm = new VM({
    sandbox: {
        Proxy: undefined
    },
    timeout: 100
});

Promise를 사용하면 시간 초과되지 않는 코드를 작성할 수도 있습니다.

"use strict";
const {VM} = require('vm2');
const untrusted = '(' + function(){
    Promise.resolve().then(a=>{
        while(1){}
    });
}+')()';
try{
    console.log(new VM({timeout:10}).run(untrusted));
}catch(x){
    console.log(x);
}

여기서 문제는 .then이 나중에 마이크로태스크 대기열에서 호출될 함수를 대기열에 넣게 된다는 것입니다.
이 문제를 해결하려면 자체 Promise.then 및 관련 함수를 작성하거나 Promise를 비활성화해야 합니다.

또한 이것은 작동합니다.

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

const script = '(' + function() {
    (async function x(){
        await {then: y=>y()};
        while(1){}
    })();
}+')()';

new VM({timeout:10}).run(script);

따라서 Promise를 재정의하는 것만으로는 작동하지 않습니다.
이 문제를 해결하는 방법을 모릅니다.

아직 열려 있지만 README에 설명을 추가하여 잠재적 인 사용자에게 경고해야합니다. 이 취약점은 샌드박스를 탈출할 수 있게 하여 라이브러리의 목적을 무효화합니다.

추가 정보가 업데이트되었습니다 https://github.com/patriksimek/vm2/commit/77f5265ab53b87864a312156ee62b1082787e9b0#diff -04c6e90faac2675aa89e2176d2eec7d8. 그리고 이것이 샌드 박스를 탈출하는 데 어떻게 사용될 수 있는지 모르겠습니다. 스크립트가 실행되어야하는 의도 된 시간 프레임 만 벗어날 수 있습니다.

아마도 이것은 자체 문제일 수 있지만 NodeVM이 "시간 초과"를 지원하지 않는 이유는 무엇입니까?

@crowder NodeVM에는 setTimeout, setInterval 및 setImmediate가 있기 때문에 시간 제한을 피하는 것이 쉽습니다. 다른 이유도있을 수 있지만 NodeVM은 사용하지 않고 VM 만 사용합니다.

@XmiliaH 는 최소한 의도하지 않은 무한 루프를 방지하는 시간 초과를 구현하지 않습니까?
악의적 인 while (true) + setTimeout 조합은 여전히 ​​문제가 될 수 있지만 실수로 수행 된 단순하고 의도하지 않은 무한 루프는 시간 제한을 지원하여 처리 할 수 ​​있습니다.

내 관심사는 NodeVM이 호스트 모듈일 수 있는 모듈을 요구할 수 있고 전역 상태를 변경하는 동안 시간이 초과되는 것이 좋지 않을 수 있다는 것입니다. 또한 NodeVM은 모듈을 반환하고 사용자는 모듈에 의해 노출된 함수를 호출할 가능성이 높지만 시간 초과는 함수 호출이 아닌 모듈 로딩에만 적용됩니다.
시간 초과가 있는 함수를 호출하려면 다음과 같이 직접 구현할 수 있습니다.

function doWithTimeout(fn, timeout) {
    let ctx = CACHE.timeoutContext;
    let script = CACHE.timeoutScript;
    if (!ctx) {
        CACHE.timeoutContext = ctx = vm.createContext();
        CACHE.timeoutScript = script = new vm.Script('fn()', {
            filename: 'timeout_bridge.js',
            displayErrors: false
        });
    }
    ctx.fn = fn;
    try {
        return script.runInContext(ctx, {
            displayErrors: false,
            timeout
        });
    } finally {
        ctx.fn = null;
    }
}

좋은 지적 @XmiliaH 그리고 예를 들어 주셔서 감사합니다.
귀하의 예가 vm2가 아닌 vm 패키지를 사용하고 있음을 알 수 있습니다.
vm2를 사용할 수 있고 여전히 시간 초과할 수 있으면 좋을 것입니다.

@szydan 내가 게시한 코드는 VM2에서 VM 시간을 초과하는 데 사용됩니다. NodeVM에도 시간 초과가 있는 경우 동일한 기능을 사용합니다.