tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: PATCH: fix for asset service (branch-3-0 2005-03-16)
Date Mon, 21 Mar 2005 14:11:05 GMT
>  All a CHF can do is confirm that the content that has
been hashed is almost certainly identical with another piece of content
that produced the same digest.

Exactly.  And that's all that's necessary.  That's a near perfect
credential because it is non-trivial (i.e., virtually impossible) to
generate the digest without the file.  The digest is long enough that
you aren't going to guess it (not in the lifespan of the universe). As
far as I understand it, this is exactly the kind of thing CHF are for.

You can overide the asset service in both 3.0 and 3.1 to fit your
needs ... but all our energies are better spent elsewhere.


On Mon, 21 Mar 2005 14:42:53 +0100, David White <dw11610@onemail.at> wrote:
> On Mon, 2005-03-21 at 07:58 -0500, Howard Lewis Ship wrote:
> > In a cluster, there's no guarantee that every request will be
> > processed by the same server.  Especially for the asset service, which
> > is not URL encoded (no session id is passed in the URL, though it may
> > come up in a cookie).
> >
> > Therefore server A may render the page and read the spec, and server B
> > may receive the asset request and fail because it's not in your
> > registry of valid assets.
> >
> > The correct approach is the one I developed for 3.1 and Paul back
> > ported to 3.0.3.  It's basic security ... you are allowed access if
> > you can prove that you should have access, by having a credential only
> > the server can provide.  The MD5 digest of the file can only be
> > generated by the server (which has the file), so that's a good
> > credential.
> 
> The asset service has access to every single resource on the classpath
> as it stands.
> 
> Say there were a security problem in a particular revision of a
> publically released Java class. An attacker can now use Tapestry's asset
> service to create an effective vulnerablity scanner that can provide a
> high degree of confidence about the presence of a particular version of
> a vulnerable class.
> 
> My problem with this solution is that it is a misuse of cryptographic
> hash functions. All a CHF can do is confirm that the content that has
> been hashed is almost certainly identical with another piece of content
> that produced the same digest. That's it, it serves NO other purpose.
> Your are ignoring the possibility that the attacker may already know the
> content by some other mechanism.
> 
> This problem won't go away until the asset service loses the ability to
> serve any resource reachable by the ClassLoader. An even more basic
> security principle is to deny everything, and permit only well-known,
> well-defined behaviors.
> 
> Your objection is valid for a clustered environment. This implies that
> the asset service must be stateful if it is to be secure. A patch will
> be forthcoming.
> 
> Thanks again,
> 
> David WHITE
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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


Mime
View raw message