classloader security problem

[Will Glass-Husain <wg...@forio.com>]

Hi,

I'm conducting an audit of security-related issues for our Velocity-based web application.  

In February there was a lengthy thread about the dangers of allowing untrusted templates to call getClassLoader, which can then be used to load an arbitrary class and call an arbitrary method.

Christopher Reck proposed to modify the velocity code to avoid retrieving a classloader.    
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102&msgNo=5980

Attila Szegedi proposed using the Java security model instead to restrict calls to getClassLoader instead.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-dev@jakarta.apache.org&msgNo=6012

Has anyone successfully implemented Attila's approach?  I've looked into it, and it is highly complex.   In particular, it doesn't seem easy to restrict an arbitrary class or package (org.apache.velocity.runtime.parser.node) by turning off a specific property.  As I understand it, I'd have to break those classes into a separate jar file, and turn ON all properties except the ones I want to restrict.

Christopher's suggestion seems reasonable, and looking at the code probably not difficult to implement.  (modify the execute method for half a dozen of the classes in o.a.v.runtime.parser.node).  But I suspect this won't make it into the core code base given the recent lack of committer activity.  If I end up implementing this, I'll post a note for interested parties. 

This seems a critical issue in regards to Velocity web security.  I have several examples of code that a malicious user could put into a template that would cause harm to a system.  Appreciate any advice.

Best, WILL

_______________________________________
Forio Business Simulations
Will Glass-Husain
(415) 440-7500 phone
(415) 235-4293 mobile

wglass@forio.com
www.forio.com