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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
