ScriptRuntime.initStandardObjects should be factored into sections, particularly lazilyNames

RESOLVED INVALID

Status

defect
RESOLVED INVALID
11 years ago
4 years ago

People

(Reporter: bugs, Unassigned)

Tracking

Details

Attachments

(1 attachment)

Reporter

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: 1.7R1

Attempting to use Rhino to evaluate JavaScript expressions.  These expressions are not necessarily trusted, and have no reason to directly callback to Java, unless specific functionality is explicitly exported into the JavaScript context.

Calling Context.setClassShutter(...) is a start; however, the "lazilyNames" used by ScriptRuntime.initStandardObjects (called by Context.initStandardObjects(...)) still inserts references to org.mozilla.javascript.NativeJavaTopPackage ("Packages", "java", "javax", "org", "com", "edu", "net", "getClass"), org.mozilla.javascript.JavaAdapter ("JavaAdapter"), and org.mozilla.javascript.ImporterTopLevel ("JavaImporter").  These are not necessary for this and other use-cases, and there should be a method to make these optional.

It is not currently possible (without mass copy & paste) to avoid these declarations without loosing all the other core functionality provided by the initStandardObjects method, particularly all the Native*.init(...) calls for NativeObject, NativeError, NativeGlobal, NativeArray, NativeString, etc.

Reproducible: Always




Other keywords: Sandbox

Comment 1

11 years ago
One idea would be to add a variant of initStandardObjects that takes a filter argument to let embedders decide which global objects to set, similar to java.io.File.list(FilenameFilter):

cx.initStandardObjects(new GlobalObjectFilter() {
    public boolean accept(String name, Object value) {
       return !(value instanceof NativeJavaTopPackage) && 
              !"getClass".equals(name);
    }
});

Comment 3

10 years ago
Since the primary issue appears to be the LiveConnect classes, what about splitting initStandardObjects into initSafeStandardObjects which does everything in initStandardObjects except initialize the LiveConnect stuff, and initStandardObjects which wraps around it and adds the LiveConnect stuff. Then secure environments can just use initSafeStandardObjects instead.
Reporter

Comment 4

10 years ago
That (comment #3) would work for me!

Comment 5

10 years ago
Ok, this patch should implement initSafeStandardObjects.
It compiles fine, and packages are still available to the shell. I haven't done thorough testing, I don't know what I'd test for/with, but this should work theoretically.
Attachment #397491 - Flags: review+
Reporter

Comment 6

4 years ago
This was fixed at https://github.com/mozilla/rhino/issues/170 .  (Thanks, Greg!)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.