You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Paul Ferraro (JIRA)" <ta...@jakarta.apache.org> on 2005/03/17 19:48:20 UTC
[jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
Paul Ferraro resolved TAPESTRY-278:
-----------------------------------
Resolution: Fixed
Fix Version: 3.0.3
Fixed security flaw by requiring all asset service requests to specify a correct resource checksum. Default checksum implementation uses Hex encoded MD5 hash. Implementation may be overridden by re-implementing AbstractEngine.createResourceChecksumSource(). Fix is based largely on new code in 3.1 branch.
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
> Assignee: Paul Ferraro
> Fix For: 3.0.3
> Attachments: AssetService.patch
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by David White <dw...@onemail.at>.
On Sun, 2005-03-20 at 13:43 -0500, Nathan Kopp wrote:
> Robert Zeigler <rd...@u.arizona.edu> wrote...
> >
> > Meaning no offense, but, this idea sounds like hell to me. Do I, or do
> > you, really want to waste time editing a config file somewhere because I
> > added three new images? Or 1000? Or 2000? I maintain an app right now
> > which contains over 3000 images so the numbers aren't far-fetched.
>
> First, thanks for Howard for coming up with a creative solution quickly,
> even if it's not completely satisfactory for everyone.
>
> Two opinions/thoughts:
> 1) Personally, I think that, unless otherwise configured, the asset service
> should follow the standard web application protocol and (by default) hide
> everything in the WEB-INF folder. This would mean not using a classloader
> for loading assets (as suggested by David White). Of course, this would
> break backwards compatibility. I think you could whitelist certain folders
> within WEB-INF to allow them to be visible, but I think the developer should
> be forced to intentionally do this, since it is nonstandard and potentiall
> unsafe. At least that's how I see it.
>
I think anything else is asking for serious trouble. Imagine if someone
were to do a firewall/router configuration interface in Tapestry (this
is pretty close to the sort of thing my project is working on, but
possibly even *more* sensitive).
> 2) Aren't all assets referenced in some way by components, before the user
> requests them?
Thanks for mentioning this. I saw this auditing the code and am pursuing
this possibility to solve the problem in a reasonable way. A diff to the
3-0-branch as of 2005-03-16 is on its way.
I'll be able to test this tomorrow (CET), hopefully a patch against this
version will be forthcoming on this list.
David WHITE
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Nathan Kopp <nk...@mailshell.com>.
Robert Zeigler <rd...@u.arizona.edu> wrote...
>
> Meaning no offense, but, this idea sounds like hell to me. Do I, or do
> you, really want to waste time editing a config file somewhere because I
> added three new images? Or 1000? Or 2000? I maintain an app right now
> which contains over 3000 images so the numbers aren't far-fetched.
First, thanks for Howard for coming up with a creative solution quickly,
even if it's not completely satisfactory for everyone.
Two opinions/thoughts:
1) Personally, I think that, unless otherwise configured, the asset service
should follow the standard web application protocol and (by default) hide
everything in the WEB-INF folder. This would mean not using a classloader
for loading assets (as suggested by David White). Of course, this would
break backwards compatibility. I think you could whitelist certain folders
within WEB-INF to allow them to be visible, but I think the developer should
be forced to intentionally do this, since it is nonstandard and potentiall
unsafe. At least that's how I see it.
2) Aren't all assets referenced in some way by components, before the user
requests them? If so, then a whitelist could be automatically generated at
run time by the components that expose these assets. There should be no
need manually configure the whitelist. Of course, in some applications this
whitelist could grow quite large and consume lots of memory, so things
wouldn't necessarily have to stay in the whitelist indefinitely... next time
a component exposes an asset, the asset would be once again added to the
whitelist.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by David White <dw...@onemail.at>.
On Sat, 2005-03-19 at 11:35 -0700, Robert Zeigler wrote:
> David White wrote:
> > Please reconsider this solution. A project I am involved in is using
> > Tapestry on a resource-constrained device, and noone was happy about
> > calculating an MD5 on assets on every access.
>
> How would you be calculating an md5 on assets on every access?
> I haven't looked at the patch in detail, but my understanding is that
> you compute the md5 once, the first time the asset is accessed. The has
> is then stored. The next time the asset is accessed, you supply the
> stored md5. Even if you're doing the comparison, you're essentially
> comparing the request parameter with the previously computed and cached
> hash; it's a simple string comparison, rather than a recompute of the hash.
>
Checking the code, it is trivially possible to produce an (in theory)
infinite number of distinct yet equivalent URL's that will force a
recompute-and-cache, e.g. for /a/b/c.gif thanks to our friends '.' and
'..'. DoS, anyone?
> <snip>
> > My suggestion is the following:
> >
> > In a Tapestry deployment, require that resources accessible to the asset
> > service be explicitly declared in the application specification.
> > Anything that is not on the asset whitelist is invisible to the asset
> > service.
> </snip>
>
> Meaning no offense, but, this idea sounds like hell to me. Do I, or do
> you, really want to waste time editing a config file somewhere because I
> added three new images? Or 1000? Or 2000? I maintain an app right now
> which contains over 3000 images so the numbers aren't far-fetched.
> And
> don't tell me that regular expressions are the answer, either.
> 1) It's difficult to come up with an expression (or set of expressions)
> that covers all valid files and which also excludes all invalid files.
> 2) Even conceding that it's possible to accomplish #1, should users be
> required to master regex. before being able to utilize assets?
3) It may fail catastrophically if the user has not mastered regexes, by
allowing directory traversal sequences and possibly other nastiness in
calls to the asset service.
No, regex or wildcards WILL NOT make the problem go away.
Does this app really pack many thousands of images into the WAR? That
sounds quite unpleasant to deal with. How does it manage so many
pictures? What can be done in this app about broken or inappropriate
content?
My $0.02 -- don't use the ClassLoader for this kind of heavy lifting. It
sounds like you need a custom service that e.g. pulls the images from a
database as BLOBs or something.
>
> As noted before, the md5 has is only computed once, anyway, and you can
> override the hash mechanism to reduce computational complexity and costs.
>
> Robert
Reducing the size of the hash code makes brute-force attacks possible.
This is very, very bad. Remember, many, many Java implementations can
easily escape from their classpath with directory traversal sequences.
Consider the implications of this.
In the particular project I am working on, the impact of this bug is
terrifying. The problem needs to be solved correctly, and not with half
measures.
I mean no offence, and I hope you and other Tapestry contributors can
see this objection as constructive criticism. Thanks for your attention.
David WHITE
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by Robert Zeigler <rd...@u.arizona.edu>.
David White wrote:
> Please reconsider this solution. A project I am involved in is using
> Tapestry on a resource-constrained device, and noone was happy about
> calculating an MD5 on assets on every access.
How would you be calculating an md5 on assets on every access?
I haven't looked at the patch in detail, but my understanding is that
you compute the md5 once, the first time the asset is accessed. The has
is then stored. The next time the asset is accessed, you supply the
stored md5. Even if you're doing the comparison, you're essentially
comparing the request parameter with the previously computed and cached
hash; it's a simple string comparison, rather than a recompute of the hash.
<snip>
> My suggestion is the following:
>
> In a Tapestry deployment, require that resources accessible to the asset
> service be explicitly declared in the application specification.
> Anything that is not on the asset whitelist is invisible to the asset
> service.
</snip>
Meaning no offense, but, this idea sounds like hell to me. Do I, or do
you, really want to waste time editing a config file somewhere because I
added three new images? Or 1000? Or 2000? I maintain an app right now
which contains over 3000 images so the numbers aren't far-fetched. And
don't tell me that regular expressions are the answer, either.
1) It's difficult to come up with an expression (or set of expressions)
that covers all valid files and which also excludes all invalid files.
2) Even conceding that it's possible to accomplish #1, should users be
required to master regex. before being able to utilize assets?
As noted before, the md5 has is only computed once, anyway, and you can
override the hash mechanism to reduce computational complexity and costs.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by "matthew c. mead" <m-...@goof.com>.
Howard has talked about this fix in several posts recently.
It calculates the hash once for the life of the engine and caches it.
It is also very easy to override this and plug in your own
ResourceChecksumSource that performs a computationally inconsequential
calculation instead. Several readers have suggested a CRC32 checksum or
a MD5 on the first few KB of the file.
-matt
David White wrote:
>Please reconsider this solution. A project I am involved in is using
>Tapestry on a resource-constrained device, and noone was happy about
>calculating an MD5 on assets on every access.
>
>I think the root problem here is that the asset service ends up
>delegating to at least one ClassLoader via the IResourceResolver
>interface. This overloading of functionality permits the service to
>access pretty much any resource it wants. If the underlying ClassLoader
>implementation is permissive enough, this can include directory
>traversals, and in many cases even directory browsing! This solution is
>computationally expensive and seems to miss the point entirely.
>
>My suggestion is the following:
>
>In a Tapestry deployment, require that resources accessible to the asset
>service be explicitly declared in the application specification.
>Anything that is not on the asset whitelist is invisible to the asset
>service.
>
>This solves a number of problems with the asset service, including the
>potential to download class files and specifications which do not
>concern the asset service.
>
>Thanks,
>
>David WHITE
>
>On Thu, 2005-03-17 at 19:48 +0100, Paul Ferraro (JIRA) wrote:
>
>
>> [ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
>>
>>Paul Ferraro resolved TAPESTRY-278:
>>-----------------------------------
>>
>> Resolution: Fixed
>> Fix Version: 3.0.3
>>
>>Fixed security flaw by requiring all asset service requests to specify a correct resource checksum. Default checksum implementation uses Hex encoded MD5 hash. Implementation may be overridden by re-implementing AbstractEngine.createResourceChecksumSource(). Fix is based largely on new code in 3.1 branch.
>>
>>
>>
>>>Tapestry 3.0.2 asset service has security flaw
>>>----------------------------------------------
>>>
>>> Key: TAPESTRY-278
>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>> Project: Tapestry
>>> Type: Bug
>>> Components: Framework
>>> Versions: 3.0.2
>>> Environment: Tomcat 5, JDK 1.4
>>> Reporter: Nathan Kopp
>>> Assignee: Paul Ferraro
>>> Fix For: 3.0.3
>>> Attachments: AssetService.patch
>>>
>>>The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
>>>The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
>>>Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
>>>* View the web.xml file:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
>>>* View the tapestry.application file:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
>>>* View a raw JSP file:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
>>>* Download a few class files that are part of the application:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by David White <dw...@onemail.at>.
Please reconsider this solution. A project I am involved in is using
Tapestry on a resource-constrained device, and noone was happy about
calculating an MD5 on assets on every access.
I think the root problem here is that the asset service ends up
delegating to at least one ClassLoader via the IResourceResolver
interface. This overloading of functionality permits the service to
access pretty much any resource it wants. If the underlying ClassLoader
implementation is permissive enough, this can include directory
traversals, and in many cases even directory browsing! This solution is
computationally expensive and seems to miss the point entirely.
My suggestion is the following:
In a Tapestry deployment, require that resources accessible to the asset
service be explicitly declared in the application specification.
Anything that is not on the asset whitelist is invisible to the asset
service.
This solves a number of problems with the asset service, including the
potential to download class files and specifications which do not
concern the asset service.
Thanks,
David WHITE
On Thu, 2005-03-17 at 19:48 +0100, Paul Ferraro (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
>
> Paul Ferraro resolved TAPESTRY-278:
> -----------------------------------
>
> Resolution: Fixed
> Fix Version: 3.0.3
>
> Fixed security flaw by requiring all asset service requests to specify a correct resource checksum. Default checksum implementation uses Hex encoded MD5 hash. Implementation may be overridden by re-implementing AbstractEngine.createResourceChecksumSource(). Fix is based largely on new code in 3.1 branch.
>
> > Tapestry 3.0.2 asset service has security flaw
> > ----------------------------------------------
> >
> > Key: TAPESTRY-278
> > URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> > Project: Tapestry
> > Type: Bug
> > Components: Framework
> > Versions: 3.0.2
> > Environment: Tomcat 5, JDK 1.4
> > Reporter: Nathan Kopp
> > Assignee: Paul Ferraro
> > Fix For: 3.0.3
> > Attachments: AssetService.patch
> >
> > The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> > The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> > Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> > * View the web.xml file:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> > * View the tapestry.application file:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> > * View a raw JSP file:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> > * Download a few class files that are part of the application:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>
--
David White <dw...@onemail.at>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org