You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Henning Schmiedehausen (JIRA)" <ji...@apache.org> on 2006/09/06 12:23:24 UTC
[jira] Updated: (VELOCITY-179) prevent execution of methods on
Class, ClassLoader and related classes
[ http://issues.apache.org/jira/browse/VELOCITY-179?page=all ]
Henning Schmiedehausen updated VELOCITY-179:
--------------------------------------------
Bugzilla Id: (was: 20341)
Assignee: Will Glass-Husain
> prevent execution of methods on Class, ClassLoader and related classes
> ----------------------------------------------------------------------
>
> Key: VELOCITY-179
> URL: http://issues.apache.org/jira/browse/VELOCITY-179
> Project: Velocity
> Issue Type: Improvement
> Components: Source
> Affects Versions: 1.4
> Environment: Operating System: All
> Platform: All
> Reporter: Will Glass-Husain
> Assigned To: Will Glass-Husain
> Priority: Minor
> Fix For: 1.6
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org