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/[EMAIL PROTECTED]&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

[EMAIL PROTECTED]
www.forio.com

Reply via email to