Sandboxing and security

Mar 6, 2013 at 8:46 PM
Edited Mar 6, 2013 at 8:46 PM
I'm interested in ClearScript for running untrusted user-provided code for calculations and minor scripting. Of course this leads to various security concerns.

1) Resource Access: opinions on the surface area for accessing resources that the user code should not have access to? For instance, assuming I have added zero hosted objects, are there any concerns of the user breaking out of V8 into the resources of my process or of the local machine/network?
2) CPU usage: I was able to mock up the ability force a timeout on a script using TPL and ScriptEngine.Interrupt(). However, if V8 supports this natively it would be nice for ClearScript to provide API access to it.
3) Memory usage: Are there any mechanisms available to prevent excessive memory usage by the user code? Is there something in V8 that ClearScript could provide an API to?

Thanks in advance for your thoughts.
Coordinator
Mar 6, 2013 at 10:36 PM
Edited Aug 3, 2013 at 3:28 AM
Greetings jbrantly!

  1. If you don't expose any host objects, JavaScript code can only access built-ins such as Math. However, because it runs within the host's process, it could potentially attack the host by exploiting vulnerabilities in the software and hardware environment. One common technique is the heap spray.
  2. In ClearScript, V8ScriptEngine's implementation of ScriptEngine.Interrupt() is based on V8's native script interruption mechanism (V8::TerminateExecution()).
  3. Currently ClearScript does not provide a way to limit a script engine's memory usage. This is something we'd like to add in the future. In the meantime, V8 itself is limited by default to approximately 1.4 GB on 64-bit systems, and that limit is lower on 32-bit. Take a look here.
Thanks for your question!
Mar 25, 2013 at 7:10 PM
Just in case you didn't see it (and for anyone else interested in this topic), I tried addressing point #3 in a pull request here: http://clearscript.codeplex.com/SourceControl/network/forks/jbrantly/ResourceConstraints/contribution/4285
Coordinator
Mar 25, 2013 at 8:57 PM
Hello jbrantly,

Thanks for contributing! We've taken a look at your pull request (nice work!), and we're tracking the general feature here.

At the moment we're wrapping up development of ClearScript 5.2. Once that's done, we'd like to take a little time to investigate a cross-engine approach to memory limit enforcement. Our preference would be to have an engine-agnostic API if possible, but if not - and this appears likely so far - then we'll incorporate your changes.

Thanks again!
Mar 25, 2013 at 9:08 PM
Sounds good, thanks for the feedback.
Aug 7, 2013 at 3:19 PM
ClearScript,

Does your statement "If you don't expose any host objects, JavaScript code can only access built-ins such as Math" only apply when using the V8 Engine? It seems like if you use Microsoft.ClearScript.Windows.JScriptEngine for example, you could use ActiveXObject as an exploit.

Consider this script method, which is designed to let a user write a script to transform data by executing it over each row as the data is copied someplace. The following code executed just fine with the JScript engine, and row.SomeField had the contents of some-secret-file.txt in it when done.
function transform(row){ 
    // Intended use
    row.SomeField = row.Foo * row.Bar;  
    
    // Malicious use
    var fso = new ActiveXObject('Scripting.FileSystemObject');
    var f = fso.OpenTextFile('c:\\temp\\some-secret-file.txt');
    row.SomeField = f.ReadAll();
    f.Close();
    fso = null;
}
Am I missing something? Is there some way to run completely sandboxed?

Justin
Coordinator
Aug 7, 2013 at 3:57 PM
Hello jusbuc2k!

Does your statement "If you don't expose any host objects, JavaScript code can only access built-ins such as Math" only apply when using the V8 Engine?

No, it applies to all supported script engines. ClearScript does not add or remove anything from a script engine at instantiation time. Well, actually, no, that's not 100% true. ClearScript does create an object named EngineInternal for its own use, but it does not remove any built-ins.

It seems like if you use Microsoft.ClearScript.Windows.JScriptEngine for example, you could use ActiveXObject as an exploit.

Yes, that's correct. ActiveXObject is a JScript built-in. If that's a concern, you might want to do something like this before running unknown script code:
engine.Execute("delete ActiveXObject");
Good luck!