[jira] Closed: (VELOCITY-179) prevent execution of methods on Class, ClassLoader and related classes

["Henning Schmiedehausen (JIRA)" <de...@velocity.apache.org>]

     [ https://issues.apache.org/jira/browse/VELOCITY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henning Schmiedehausen closed VELOCITY-179.
-------------------------------------------


> prevent execution of methods on Class, ClassLoader and related classes
> ----------------------------------------------------------------------
>
>                 Key: VELOCITY-179
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-179
>             Project: Velocity
>          Issue Type: Improvement
>          Components: Engine
>    Affects Versions: 1.4
>         Environment: Operating System: All
> Platform: All
>            Reporter: Will Glass-Husain
>         Assigned To: Will Glass-Husain
>            Priority: Minor
>             Fix For: 1.5
>
>         Attachments: IntrospectorTestCase4.java, patch1.txt, patch2.txt, patch2b.txt, testcases.xml.patch
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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