You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Christoph Reck <Ch...@dlr.de> on 2002/02/22 14:53:30 UTC
Security issue using introspected classloader
Hi,
sorry to be here a devils advocate...
People like velocity because it allows securer page design that
JSP. Since velocity is so simple but powerfull it is not as
secure as some would like it.
I attached an example template to demonstrate the security attack.
Velocity does not allow:
* accessing fields of a class
* calling methods of something that is not a class instance
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!).
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.
--
:) Christoph Reck
Re: Security issue using introspected classloader
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/27/02 5:00 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> Another thought: there's a danger in bundling a default security template
> with Velocity: it can lull people in a false sense of security. People will
> mostly install the bundled default policy, and if anything goes wrong
> they'll come here and blame the developers for the security hole. So, if we
> decide to provide a default Vel security policy template, we'll have to make
> it *very* restrictive in order to save ourselves from potential serious
> buttkicking. Also, I'm speaking of "policy templates" since they need much
> tailoring: the codebase URL is specific to the actual location of the
> Velocity jar; a file read permission must be given to the location of the
> template files, which is again system-dependent, etc.
You are right. I am just going to document the concept for 1.3 and leave it
at that. That way the subject is addressed, yet no warranty will be
expressed or implied :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by Attila Szegedi <sz...@freemail.hu>.
Another thought: there's a danger in bundling a default security template
with Velocity: it can lull people in a false sense of security. People will
mostly install the bundled default policy, and if anything goes wrong
they'll come here and blame the developers for the security hole. So, if we
decide to provide a default Vel security policy template, we'll have to make
it *very* restrictive in order to save ourselves from potential serious
buttkicking. Also, I'm speaking of "policy templates" since they need much
tailoring: the codebase URL is specific to the actual location of the
Velocity jar; a file read permission must be given to the location of the
template files, which is again system-dependent, etc.
Attila.
--
Attila Szegedi
home: http://www.szegedi.org
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: "Velocity Developer's List" <ve...@jakarta.apache.org>
Sent: 2002. február 26. 12:32
Subject: Re: Security issue using introspected classloader
> On 2/26/02 6:22 AM, "Jose Alberto Fernandez" <j_...@yahoo.com>
> wrote:
>
> > --- Attila Szegedi <sz...@freemail.hu> wrote: >
> > The administrator need not know every detail of the
> >> product code, however
> >> administrator should know which permissions exist in
> >> a system (in this case,
> >> Java2 runtime) and try to figure out the tightest
> >> policy that still allows
> >> the product to work - usually by first restricting
> >> everything, and loosening
> >> until it works. If any runtime permission check
> >> fails, Java will produce a
> >> SecurityException with the lacking permission name
> >> in the message, so
> >> adjustment is easy. After only several iterations of
> >> run-loose
> >> policy-run-loose policy-... an administrator will
> >> usually empirically find
> >> an appropriate configuration.
> >>
> >
> > If and only if the administrator has a full
> > codecoverage suit available that he can rely will take
> > check all possible parts of the application.
> >
> >> Nevertheless, a default (very restrictive) policy
> >> file can be included with
> >> velocity - as I said earlier, most runtime
> >> permissions should be revoked
> >> from the o.a.v.runtime.parser.node package.
> >>
> >
> > Fine, but I think the Velocity team should be a
> > responsible Security conscious bunch and do an
> > auditing of the Velocity API and make a security
> > recommendation for administrators to use.
>
> We'll be happy to include an example - it really won't be that hard.
> However, I believe that the responsibility still falls to the user.
>
> >
> > If an application wants to use more than that,
> > it should be for the administrator to decide whether
> > to allow it or not.
> >
> > But you cannot just say, oh let them loosen security
> > a bit at the time until it works. No security
> > conscious shop (like a Bank) should allow that
> > approach.
>
> ? Attila was advocating locking everything down and then easing
> restrictions on only the pieces that are needed. That's a conventional
> approach, isn't it?
>
> --
> Geir Magnusson Jr.
geirm@optonline.net
> System and Software Consulting
> "Whoever would overthrow the liberty of a nation must begin by subduing
the
> freeness of speech." - Benjamin Franklin
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/26/02 6:22 AM, "Jose Alberto Fernandez" <j_...@yahoo.com>
wrote:
> --- Attila Szegedi <sz...@freemail.hu> wrote: >
> The administrator need not know every detail of the
>> product code, however
>> administrator should know which permissions exist in
>> a system (in this case,
>> Java2 runtime) and try to figure out the tightest
>> policy that still allows
>> the product to work - usually by first restricting
>> everything, and loosening
>> until it works. If any runtime permission check
>> fails, Java will produce a
>> SecurityException with the lacking permission name
>> in the message, so
>> adjustment is easy. After only several iterations of
>> run-loose
>> policy-run-loose policy-... an administrator will
>> usually empirically find
>> an appropriate configuration.
>>
>
> If and only if the administrator has a full
> codecoverage suit available that he can rely will take
> check all possible parts of the application.
>
>> Nevertheless, a default (very restrictive) policy
>> file can be included with
>> velocity - as I said earlier, most runtime
>> permissions should be revoked
>> from the o.a.v.runtime.parser.node package.
>>
>
> Fine, but I think the Velocity team should be a
> responsible Security conscious bunch and do an
> auditing of the Velocity API and make a security
> recommendation for administrators to use.
We'll be happy to include an example - it really won't be that hard.
However, I believe that the responsibility still falls to the user.
>
> If an application wants to use more than that,
> it should be for the administrator to decide whether
> to allow it or not.
>
> But you cannot just say, oh let them loosen security
> a bit at the time until it works. No security
> conscious shop (like a Bank) should allow that
> approach.
? Attila was advocating locking everything down and then easing
restrictions on only the pieces that are needed. That's a conventional
approach, isn't it?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
--- Attila Szegedi <sz...@freemail.hu> wrote: >
The administrator need not know every detail of the
> product code, however
> administrator should know which permissions exist in
> a system (in this case,
> Java2 runtime) and try to figure out the tightest
> policy that still allows
> the product to work - usually by first restricting
> everything, and loosening
> until it works. If any runtime permission check
> fails, Java will produce a
> SecurityException with the lacking permission name
> in the message, so
> adjustment is easy. After only several iterations of
> run-loose
> policy-run-loose policy-... an administrator will
> usually empirically find
> an appropriate configuration.
>
If and only if the administrator has a full
codecoverage suit available that he can rely will take
check all possible parts of the application.
> Nevertheless, a default (very restrictive) policy
> file can be included with
> velocity - as I said earlier, most runtime
> permissions should be revoked
> from the o.a.v.runtime.parser.node package.
>
Fine, but I think the Velocity team should be a
responsible Security conscious bunch and do an
auditing of the Velocity API and make a security
recommendation for administrators to use.
If an application wants to use more than that,
it should be for the administrator to decide whether
to allow it or not.
But you cannot just say, oh let them loosen security
a bit at the time until it works. No security
conscious shop (like a Bank) should allow that
approach.
Jose Alberto
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by Attila Szegedi <sz...@freemail.hu>.
The administrator need not know every detail of the product code, however
administrator should know which permissions exist in a system (in this case,
Java2 runtime) and try to figure out the tightest policy that still allows
the product to work - usually by first restricting everything, and loosening
until it works. If any runtime permission check fails, Java will produce a
SecurityException with the lacking permission name in the message, so
adjustment is easy. After only several iterations of run-loose
policy-run-loose policy-... an administrator will usually empirically find
an appropriate configuration.
Nevertheless, a default (very restrictive) policy file can be included with
velocity - as I said earlier, most runtime permissions should be revoked
from the o.a.v.runtime.parser.node package.
--
Attila Szegedi
home: http://www.szegedi.org
----- Original Message -----
From: "Jose Alberto Fernandez" <j_...@yahoo.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: 2002. február 26. 2:27
Subject: Re: Security issue using introspected classloader
I think that at least Velocity should provide a security policy file for
Velocity
that makes sure all security holes are plugged. You can not expect every
administrator to know every detail of the code of product that is installed.
Jose Alberto
> Cheers,
> Attila.
>
> --
> Attila Szegedi
> home: http://www.szegedi.org
>
> ----- Original Message -----
> From: "Christoph Reck" <Ch...@dlr.de>
> To: <ve...@jakarta.apache.org>
> Sent: 2002. február 22. 14:53
> Subject: Security issue using introspected classloader
>
>
> > Hi,
> >
> > sorry to be here a devils advocate...
> >
> > People like velocity because it allows securer page design that
> > JSP. Since velocity is so simple but powerfull it is not as
> > secure as some would like it.
> >
> > I attached an example template to demonstrate the security attack.
> >
> > Velocity does not allow:
> > * accessing fields of a class
> > * calling methods of something that is not a class instance
> >
> > 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!).
> >
> > 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.
> >
> > --
> > :) Christoph Reck
>
>
> --------------------------------------------------------------------------
--
> ----
>
>
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Attila Szegedi" <sz...@freemail.hu>
> 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.
>
I think that at least Velocity should provide a security policy file for Velocity
that makes sure all security holes are plugged. You can not expect every
administrator to know every detail of the code of product that is installed.
Jose Alberto
> Cheers,
> Attila.
>
> --
> Attila Szegedi
> home: http://www.szegedi.org
>
> ----- Original Message -----
> From: "Christoph Reck" <Ch...@dlr.de>
> To: <ve...@jakarta.apache.org>
> Sent: 2002. február 22. 14:53
> Subject: Security issue using introspected classloader
>
>
> > Hi,
> >
> > sorry to be here a devils advocate...
> >
> > People like velocity because it allows securer page design that
> > JSP. Since velocity is so simple but powerfull it is not as
> > secure as some would like it.
> >
> > I attached an example template to demonstrate the security attack.
> >
> > Velocity does not allow:
> > * accessing fields of a class
> > * calling methods of something that is not a class instance
> >
> > 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!).
> >
> > 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.
> >
> > --
> > :) Christoph Reck
>
>
> ----------------------------------------------------------------------------
> ----
>
>
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by 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 |
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
Re: Security issue using introspected classloader
Posted by Attila Szegedi <sz...@freemail.hu>.
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.
Cheers,
Attila.
--
Attila Szegedi
home: http://www.szegedi.org
----- Original Message -----
From: "Christoph Reck" <Ch...@dlr.de>
To: <ve...@jakarta.apache.org>
Sent: 2002. február 22. 14:53
Subject: Security issue using introspected classloader
> Hi,
>
> sorry to be here a devils advocate...
>
> People like velocity because it allows securer page design that
> JSP. Since velocity is so simple but powerfull it is not as
> secure as some would like it.
>
> I attached an example template to demonstrate the security attack.
>
> Velocity does not allow:
> * accessing fields of a class
> * calling methods of something that is not a class instance
>
> 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!).
>
> 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.
>
> --
> :) Christoph Reck
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/22/02 9:20 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> "Geir Magnusson Jr." wrote:
>> [snip]
>>>
>>> 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.
>>
>> Would it be shorter to just prevent anyone from just getting a classloader?
>> How many ways are there to do it?
>
> I can think of:
>
> Thread.getContextClassLoader()
> Class.getClassLoader()
>
> ... but there might be some more. Or in future JDKs some might be added...
You are right... No point in trying to predict the future. Just key off of
it being a ClassLoader.
>
> Does the velocity code still have some direct reflection calls to
> class.getMethod() that is not using the introspector? If this is the
> case, then there are several places to plug. Otherwise I believe it
> make no difference to avoid returing a classloader, or just rejecting
> to call a method on a classloader.
I have an outstanding promise to focus this stuff, and will do after 1.3
release - then we can add it as some kind of filter.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by Christoph Reck <Ch...@dlr.de>.
"Geir Magnusson Jr." wrote:
>[snip]
> >
> > 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.
>
> Would it be shorter to just prevent anyone from just getting a classloader?
> How many ways are there to do it?
I can think of:
Thread.getContextClassLoader()
Class.getClassLoader()
... but there might be some more. Or in future JDKs some might be added...
Does the velocity code still have some direct reflection calls to
class.getMethod() that is not using the introspector? If this is the
case, then there are several places to plug. Otherwise I believe it
make no difference to avoid returing a classloader, or just rejecting
to call a method on a classloader.
:) Christoph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security issue using introspected classloader
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/22/02 8:53 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> Hi,
>
> sorry to be here a devils advocate...
>
> People like velocity because it allows securer page design that
> JSP. Since velocity is so simple but powerfull it is not as
> secure as some would like it.
>
> I attached an example template to demonstrate the security attack.
>
> Velocity does not allow:
> * accessing fields of a class
> * calling methods of something that is not a class instance
>
> 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!).
I was playing with this a while ago - it's kinda fun, but yes, indeed, a
hole.
>
> 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.
Would it be shorter to just prevent anyone from just getting a classloader?
How many ways are there to do it?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>