Re: Security issue using introspected classloader

[ed...@collab.net]

On Fri, Feb 22, 2002 at 02:53:30PM +0100, Christoph Reck wrote:
[snip]
> But it allows you to get the class and its classloader, thus
> one can create instances of whatever is loadable and instantiable.
> Still you cannot do something like System.exit() since one 
> cannot get hold of an instance of the System.class (there is no
> constructor!).

You don't need a constructor to run static methods -- you can get
reference to a Method, and invoke it.  I've attached a sample script I
wrote some time ago to which includes this, and demonstrates running an
arbitrary command (it could be shorter than this and still be effective
-- I just added enough to get it to run without showing errors).
It assumes you have an object in the context named currentUser.


> PROPOSAL:
> I propose adding another configuration parameter and add a
> check on this in the introspector to avoid calling any methods
> if the object to be introspected is an instance of a classloader.
[snip]

You'd have to restrict Class -- or at least Class.forName() -- as well.
Catching Class.forName, ClassLoader, and all of java.lang.reflect -- and
preventing them inside templates -- might be reasonable and would
prevent some attacks.  But I am inclined to believe it'd be rather
incomplete as solution (which is the same criticism I have for the Java
security model).

On Mon, Feb 25, 2002 at 03:26:36PM +0100, Attila Szegedi wrote:
> I don't think Velocity should deal with this. Access to a class loader is
> already protected by a check for the runtime permission "getClassLoader". A
> security savvy website administrator will set up a policy file and revoke
> this permission from the org.apache.velocity.runtime.parser.node package and
> that will do the trick. Same goes for preventing System.exit ("exitVM"
> permission) and all other potentially dangerous operations (see
> java.lang.RuntimePermission). Since this is addressed in Java2 security
> infrastructure, no need to reinvent the wheel here.

One key problem with this is that you may want different restrictions on
code in that package, compared with the restrictions on Velocity itself.
Velocity needs to do reflection -- and reflection + the ability to
instantiate lists is basically all you need to run untrusted code.

Have you set this up w/ Velocity?  I'm interested in looking into this
in any case, and will if/when I have time, fwiw.  But I can say right
now -- I don't trust code until someone I know has implemented something
in it.  I've seen too many broken libraries to trust any vendor without
talking to someone who's used their code/system/etc.  And all I've heard
so far of the Java security model concerned ways to circumvent it.

Anyway, given Velocity's environment, I doubt that it's straightforward
to get Java to handle permissions they way we'd want.  We're talking
about a trusted application running untrusted code in a scripting
language.  It may be possible to convince the Java security model to
handle this, but this is not the context for which it was designed --
and it's arguable that the right place to apply permissions to the
scripting language (velocity's language) is in the interpreter.

Of course -- I'm somewhat dubious about realistically allowing both the
functionality people are likely to want in something like Velocity, and
the security required to run untrusted velocity templates.  IMO, the
real solution is to avoid untrusted velocity templates, just as you'd
avoid untrusted Java code.

cheers --

Ed
-- 
   +=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
   |   Ed Korthof   |  edk@collab.net  |   650-228-2527   |
   +=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=