Return-Path: Delivered-To: apmail-jakarta-tapestry-dev-archive@www.apache.org Received: (qmail 46216 invoked from network); 20 Mar 2005 02:58:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Mar 2005 02:58:50 -0000 Received: (qmail 53594 invoked by uid 500); 19 Mar 2005 19:41:25 -0000 Delivered-To: apmail-jakarta-tapestry-dev-archive@jakarta.apache.org Received: (qmail 53325 invoked by uid 500); 19 Mar 2005 19:41:24 -0000 Mailing-List: contact tapestry-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tapestry development" Reply-To: "Tapestry development" Delivered-To: mailing list tapestry-dev@jakarta.apache.org Received: (qmail 53311 invoked by uid 99); 19 Mar 2005 19:41:24 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=FROM_ENDS_IN_NUMS,LOTS_OF_STUFF X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from viefep16-int.chello.at (HELO viefep16-int.chello.at) (213.46.255.17) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 19 Mar 2005 11:41:23 -0800 Received: from [10.8.0.32] (really [80.108.7.16]) by viefep16-int.chello.at (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050319194118.UTOG28063.viefep16-int.chello.at@[10.8.0.32]> for ; Sat, 19 Mar 2005 20:41:18 +0100 Subject: Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw From: David White To: Tapestry development In-Reply-To: <423C70E7.3040705@u.arizona.edu> References: <429794945.1111085300992.JavaMail.jira@ajax.apache.org> <1111222877.11858.13.camel@localhost> <423C70E7.3040705@u.arizona.edu> Content-Type: text/plain Date: Sat, 19 Mar 2005 20:41:21 +0100 Message-Id: <1111261281.12900.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Dropline GNOME Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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? > > > 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. > > > 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