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.