[
https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626731#comment-17626731
]
Dmitri Blinov commented on JEXL-381:
------------------------------------
IMO the idea to sandbox JEXL by default is not without good sense, since there
might be people around who are not experienced in security problems. Jexl may
provide them with some basics.
My experience in sandboxing JEXL, so that it would be difficult to use it as a
security hole, is that you need to hinder many access paths, not only disabling
access to certain packages, but preventing access to object classloader for
example, since there is possibility to obtain the restricted object by calling
ClassLoader.findClass() or Class.forName("") and bypass standard constructor
package checks. Other obvious measures are restricting access to
java.lang.System static methods, like System.exit(code). My currentl list for
completely restricted class methods is
"java.lang.System", "java.lang.Compiler", "java.lang.Process",
"java.lang.ProcessBuilder", "java.lang.Runtime",
"java.lang.RuntimePermission", "java.lang.SecurityManager", "java.lang.Thread",
"java.lang.ThreadGroup",
"java.lang.ClassLoader", "java.net.URLClassLoader", "java.io.FileDescriptor"
Here is my list to restricted constructors - IMO its ok to work with objects if
you get them somehow, via secured api, but you should not be able to create
those objects in uncontrolled manner
"java.io.File", "java.io.FileDescriptor", "java.io.FileInputStream",
"java.io.FileOutputStream",
"java.io.FilePermission", "java.io.FileReader", "java.io.FileWriter",
"java.io.PrintStream", "java.io.PrintWriter",
"java.io.RandomAccessFile", "java.io.ObjectInputStream",
"java.util.zip.ZipFile", "java.util.jar.JarFile",
"java.net.URL", "java.net.URLClassLoader"
Other resticted methods are
{code:java}
// Prevent direct invocation
if (Class.class.isAssignableFrom(clazz) && ("forName".equals(method) ||
"getClassLoader".equals(method)))
return false;
// Prevent direct invocation
if (Method.class.isAssignableFrom(clazz) && ("invoke".equals(method) ||
"setAccessible".equals(method)))
return false;
// Prevent direct invocation
if (MethodHandle.class.isAssignableFrom(clazz) &&
("invoke".equals(method) || "invokeExact".equals(method)))
return false;
// Prevent direct invocation
if (Constructor.class.isAssignableFrom(clazz) &&
"newInstance".equals(method))
return false;
// Prevent direct invocation
if (File.class.isAssignableFrom(clazz) &&
("createTempFile".equals(method) || "listRoots".equals(method)))
return false;
// Prevent direct invocation
if (URL.class.isAssignableFrom(clazz) &&
"setURLStreamHandlerFactory".equals(method))
return false;
{code}
So, there is alot to think about...
> Change default JEXL configuration to a more security-friendly behaviour
> ------------------------------------------------------------------------
>
> Key: JEXL-381
> URL: https://issues.apache.org/jira/browse/JEXL-381
> Project: Commons JEXL
> Issue Type: Improvement
> Affects Versions: 3.2.1
> Reporter: Henri Biestro
> Assignee: Henri Biestro
> Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> JEXL's default builder allows accessing and calling any public method, field
> or constructor of any public class. This might not be desirable since a quick
> exploration of JEXL will quickly conclude the library allows arbitrary
> execution through commands (ProcessBuilder) or getting to the file-system
> through URL or File. This improvement goal is to change JEXL's permeability
> as an explicit option and user decision, not a default behaviour.
> HOW:
> By changing the current JexlBuilder to use a restricted set of permissions
> whilst instantiating the Uberspect, we can ensure a minimal useful set of
> classes can be accessed and only those by default. By removing access to
> almost all classes that interact with the JVM host and file-system, we ensure
> a default isolation that would significantly reduce the ability to use JEXL
> as an attack vector.
> CAVEAT:
> This change will likely break many scripts that were dependant upon the
> default permeability.
> [~ggregory], [~dmitri_blinov] your opinions are welcome :-)
> https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
