DO NOT REPLY [Bug 20341] New: - prevent execution of methods on Class, ClassLoader and related classes

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20341>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20341

prevent execution of methods on Class, ClassLoader and related classes

           Summary: prevent execution of methods on Class, ClassLoader and
                    related classes
           Product: Velocity
           Version: 1.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Source
        AssignedTo: velocity-dev@jakarta.apache.org
        ReportedBy: wglass@forio.com


Template designers currently have the capability to acquire a ClassLoader, 
instantiate an arbitrary class, and call an arbitrary method.  (Example: [1], 
although more compact examples exist).  This is a drastic break with the MVC 
model, as template designers can execute any arbitary code.  It gets worse if 
you have untrusted template designers who might call methods that erase files, 
execute arbitrary SQL code, or shut down the VM.   This has been discussed on 
the dev list [2].

This patch prevents any method from being called on objects of a class that 
has reflection, classloader, or runtime capabilities.  (List at the end of the 
report [4]).  It's configurable with a property, but the default is ON, as 
security restrictions, IMHO, should be strict by default.

An alternate solution to this issue would be to prohibit the ClassLoader 
through the Java Security Manager, as proposed here [4].  I believe this 
solution to be too difficult for the typical developer.  It's complex, and 
requires knowledge of the Velocity source code.  Essentially, you have to 
split the files that execute the methods on the Java classes into a separate 
JAR file, then designate that jar file as not have permission to call 
getClassLoader.  This requires that you (A) know what those Velocity classes 
are (B) understand how to work with the security manager, which is quite 
complex, and (C) have to modify the Velocity package every time there is a new 
release.  I think it would be better if this is handled natively within 
Velocity.  

Finally, this patch does not include docs or test cases.  I'd be willing to 
write both, if a committer is willing to put in the patch.  

[1] Example of VTL to call arbitray method
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
dev@jakarta.apache.org&msgNo=6114

[2] Related discussion
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102&msgNo=5980 
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
user@jakarta.apache.org&msgNo=10444

[3] Classes affected

java.lang.Class
java.lang.ClassLoader
java.lang.Compiler
java.lang.Package
java.lang.Process
java.lang.InheritableThreadLocal
java.lang.Runtime
java.lang.RuntimePermission
java.lang.SecurityManager
java.lang.System
java.lang.Thread
java.lang.ThreadGroup
java.lang.ThreadLocal
java.lang.reflect.*

[4] Java security manager proposal
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
dev@jakarta.apache.org&msgNo=6012

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org