Sandboxing JavaScript runtime environment

[alterakey]

Hello,
This is my first attempt to secure the JS validator facility.

I think JS based validators are good to have, but at the same time I feel it's better to have runtime enviroments confined somehow. I have written some working exploits for RedPen 1.3 or later; if you are interested in, I'll show you.

Changes are:

• Disable intrinsic Java bridging facilities in order to execute validators
• Disable intrinsic function to load JS or enable Rhino compatibility in order to execute validators

Please review and hopefully merge. Keep up good work.
Best,
-t

[yusuke]

How about adding "java = undefined; javax = undefined; Java = undefined; load = undefined; redpenToBeBound = undefined;"); to this section, instead of introducing appllySandbox method and UnconfinedScript?

[alterakey]

I'd love to do so, but that will break a test.

In redpen-core/src/test/java/cc/redpen/validator/JavaScriptValidatorTest.java, we have:

@Test
public void testJSLiteralValidator() throws RedPenException, IOException {
    ...
    validator.scripts.add(new ...Script(validator, "testScript.js",
            "function preValidateSentence(sentence) {" +
                    // add function names to "calledFunctions" list upon function calls for the later assertions
                    // the following script is using Nashorn's lobal object "Java".type to access static member:
                    // http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html
                    "Java.type('cc.redpen.validator.JavaScriptValidatorTest').calledFunctions.add('preValidateSentence');}" +
     ...

So the test function needs the bridging facility for a legitimate purpose.

That's why I introduced UnconfinedScript.

[alterakey]

Okay, now it's gone.

[takahi-i]

👍

[yusuke]

What I understand is that this fix will prevent attacker from running malicious code on RedPen using JavaScriptValidator & JavaScript - Java bridging mechanism.

As the prerequisite, the attacker needs to get an access to the local file system. In that case, they can run any script even without JavaScriptValidator.

I mean, is this for attackers who have write access to the $REDPEN_HOME/js directory, but don't have any permission to execute scripts on that machine?

[alterakey]

Please consider on the redpen-server. It is meant to be run by a user like a web server (and redpen-server doesn’t have a privilege separation mechanism yet.)

Then someone places a validator to somewhere untrusted users can write, say the /tmp, /var/www/…, /home/ftp/… , and instructs redpen-server to run it — with the privileges of the redpen-server user. With the word whatever I mean it — arbitrary code execution.

This is what I recognize as a vulnerability. It is going to be a problem even if RedPen restrict its script directory — what if people can run arbitrary code on some cloud-based services using RedPen?

Rhino/Nashorn engines under Java 8u40 has no real protection against the problem (*1); this patch should provide only marginal one. If you cannot accept the patch, you should at least clearly warn users not to run JS validators from untrusted sources, and/or to restrict access of the redpen-server (and/or JS validator directory) to trusted parties only.

*1: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8050078