David, Could you provide more details about how they accessed /etc/passwd? thanks,
Mark -----Original Message----- From: David White [mailto:[EMAIL PROTECTED] Sent: Wed 12/28/2005 2:43 PM To: Tapestry development Subject: Re: WARNING!: Thinking about breaking asset service MD5 digest ofcertain resources On Tue, 2005-12-27 at 12:55 -0500, Jesse Kuhnert wrote: > I'm re-working some form of security back into the AssetService but am > having a real hard time justifying making the protected resources concept a > configurable option. > > Specifically, all that I intend to do initially is protect all .class > resources. It feels very inefficient to imagine iterating/loooping/hash > lookup of incoming string values to the configured resources. I'm thinking > that maybe hard-coding (in some fashion) the .class extension logic may be a > better choice until someone presents a scenerio where they feel they need > more? > Yes, I can. We had a Tapestry 3.0 app that could read and serve /etc/passwd and other nasties with appropriate path strings sent as parameters. This is potentially a very serious problem. I would suggest that assets be perhaps restricted to a particular path in the *AR where it has been deployed, like so for a resource with relative url <foo>: WEB-INF/classes/ASSETS/<foo> with no exceptions and no funky characters allowed. This would break existing apps, of course, which is terrible and bad, but preferable to the potential for harm in this behavior. The unkeyed SHA-1 hash in the current implementation is still a hole, by the way. Consider an embedded system, like a WLAN base station, using Tapestry for its web interface (similar things exist ITW). A request for the password database with a hash key obtained by running SHA-1 on the default password db would be a simple, unobtrusive, and effective scanner for such routers left in the default configuration... Hope this helps, David WHITE --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
