-
Rhino is often used with enabled liveConnect (ImporterTopLevel) that provides access to all java classes. But this opens big security issues, as soon as the user can enable custom javascript code. If this is a multi user web application, one user can quit the JVM by just typing I've experimented with a securityManager (see #861) to restrict IO in (untrusted) javascript. There is demand to provide some security in LiveConnect. But the current possibilities with ClassShutter or custom wrap factories are limited. You may have access to a class that seems to be harmless, but you've overseen that one of the methods may perform file IO (See PDDocument in this #972 (comment)) This makes it very hard for developers to build an application that is secure. What are the options:
If later, there should be a statement in the rhino documentation, that with liveConnect a perfect security is not possible. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
Case with related questions: #861 |
Beta Was this translation helpful? Give feedback.
-
Sorry I didn't answer this before -- I have been in and around some projects that embed Rhino in the past and some that still do. There are obviously bad things that can happen if you let users supply their own code for Rhino to execute in any environment that you own. By default, Rhino has no built-in APIs that can do anything other than manipulate what is inside the world of Rhino. If Rhino is initialized using InitSafeStandardObjects, then the main risks in this situation are: A) A script could allocate a huge amount of memory (You can reduce or maybe eliminate the risk of B using the "InstructionObserverThreshold" feature of the Context object in conjunction with compiled code. That lets you set a timer, so that if a script runs for too long, or is stuck in one place for too long, you can throw an exception.) If you allocate the Global object (from the "tools/shell" package) and put it on the context, then now a script can also: C) Read any file, or execute any program If you use the regular "InitStandardObjects" function, which enables the Java embedding stuff, then a script can also: D) Load any Java class that it can and call any Java functions that are accessible The safest way to avoid all of this would be to put each of your "users" in a sandbox -- not a JVM sandbox, but an OS sandbox, such as a separate Docker container (or some other kind of container) or virtual machine. Then the worst thing that they can do is trash that sandbox, and you can use various mechanisms to limit the impact of A-D above. If you don't use Global, and then D is the main risk, then it is indeed up to the Java security manager. I think that the Java community is generally pretty skeptical that you can use that to make everything OK, but I'm sure that it helps. So perfect security is NEVER possible with anything, and certainly not with Rhino, but depending on what you do there are ways to reduce the risk quite a bit. In my non-security-expert opinion, I think that giving untrusted or semi-trusted users the ability to load anything using LiveConnect is something to avoid. I think you're better off creating specific native classes using one of the other embedding options that interface with your Java code. I think that might be better for your users as well, since you have given them only a JavaScript API, rather than a JavaScript engine that executes code that looks like JavaScript but also works a bit like Java at times! |
Beta Was this translation helpful? Give feedback.
-
Thanks for your feedback. I read a lot about JEP411, for example I understand the pros and cons, but in the moment I'm afraid that the SM will be removed without replacement.
This would be also true for normal java code, if the code isn't allowed to do native calls. So putting a gate keeper before each native call will keep your system safe. (This is roughly the same, what the current security manager does) So maybe there IS hope for an alternative.
yes of course, but it is not easy to share objects across such instances (without opening new security holes)
I agree, the securityManager helps and provides 99% security (I had blocke files etc.) but I'm not sure, if I missed a thing.
After an internal discussuion, we decided to be more restrictive this way. So only real trusted users can enter or change javascript where LiveConnect is enabled. |
Beta Was this translation helpful? Give feedback.
Thanks for your feedback. I read a lot about JEP411, for example
https://www.mail-archive.com/search?l=security-dev@openjdk.java.net&q=subject:%22JEP411%5C%3A+Missing+use%5C-case%5C%3A+Monitoring+%5C%2F+restricting+libraries%22&o=newest&f=1
and there are others that rely on SecurityManager.
I understand the pros and cons, but in the moment I'm afraid that the SM will be removed without replacement.
That's why I sorted out things here to be prepared for JEP411: #1068