tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David White <dw11...@onemail.at>
Subject Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Date Sat, 19 Mar 2005 19:41:21 GMT
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

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

I mean no offence, and I hope you and other Tapestry contributors can
see this objection as constructive criticism. Thanks for your attention.


To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message