[ 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- > [EMAIL PROTECTED]&msgNo=6114 > [2] Related discussion > http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102&msgNo=5980 > http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- > [EMAIL PROTECTED]&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- > [EMAIL PROTECTED]&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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]