[ http://issues.apache.org/jira/browse/VELOCITY-179?page=all ]
Will Glass-Husain updated VELOCITY-179:
---------------------------------------
Bugzilla Id: (was: 20341)
Fix Version: 1.5
Description:
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
was:
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
Environment:
Operating System: All
Platform: All
was:
Operating System: All
Platform: All
Assign To: (was: Velocity-Dev List)
I'd like to see this go into v 1.5.
> prevent execution of methods on Class, ClassLoader and related classes
> ----------------------------------------------------------------------
>
> Key: VELOCITY-179
> URL: http://issues.apache.org/jira/browse/VELOCITY-179
> Project: Velocity
> Type: Improvement
> Components: Source
> Versions: 1.4
> Environment: Operating System: All
> Platform: All
> Reporter: 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.
-
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
