tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Taylor <DavidVTay...@cox.net>
Subject Re: [jira] Resolved: (TAPESTRY-281) asset service has security flaw
Date Wed, 16 Mar 2005 17:32:20 GMT
I fully agree with your assessment and think it is more than adequate 
for this application. Given the length of an MD5 hash it would take 
quite some time to try all possible hash values for a given asset. While 
purists might object on the basis that a brute force attack is possible, 
the risk is reasonably small unless your server is much faster than mine :)

The problem I face is that MD5 has the reputation of being a "broken" 
hash. While it can be argued at a technical level that this is an 
appropriate use of MD5, it is very difficult to convince someone less 
technical. Speaking from experience, it is no fun sitting across the 
table from Visa and government security auditors and trying to explain 
how MD5 is broken except when used in your application. The unfortunate 
reality is that the people that make the decisions just don't understand 
the details and want a "sure thing". These are the same people that 
subscribe to the idea that "nobody is ever fired for choosing IBM".

Maybe I should find some less paranoid customers...


Howard Lewis Ship wrote:

>So, you're an evil hacker and you want to suck out a Java .class file
>using the asset service.
>
>So you say, "MD5 is broken", all I have to do is a) figure out the
>name of the class and b) generate a correct MD5 digest for it.
>
>Maybe they can pick out the class name from a stack trace.
>
>That leaves (b).  If you don't know the content, or even the length,
>of the file, how would you  go about creating the MD5 digest for it? 
>Short of iterating through the possible values for a few billion
>years?
>
>Those cases where people have "cracked" MD5 ... they usually started
>with a lot more, such as a partial password, or a public key, and used
>that, along with a lot of other data, to get at the encoded data (the
>private key).
>
>In fact, MD5 is probably overkill for the Tapestry asset service use
>case, a simple CRC32 checksum would probably be more than sufficient.
>
>
>On Tue, 15 Mar 2005 18:06:38 -0500, David Taylor <DavidVTaylor@cox.net> wrote:
>  
>
>>Great, I was planning on backporting the changes this week. I was also
>>considering adding the feature of limiting the hash to the first few KB
>>of the file to avoid the performance hit when dealing with large assets.
>>One of the applications I have in the works currently serves up
>>thousands of high-res JPEG and large PDF files using dynamically created
>>assets.
>>
>>I do have one question -- are your updates a straight port of the
>>original MD5-only version or did you allow for other hash algorithms?
>>While MD5 is probably more than adequate for this use, security minded
>>businesses are afraid of MD5 because it has demonstrated collisions and
>>is considered "broken". For these clients I am planning on using SHA-256
>>since it is not yet considered to be an "evil" algorithm. If not, I
>>would be happy to help add support for other algorithms.
>>
>>Thanks for your timely contribution.
>>
>>David
>>
>>matthew c. mead wrote:
>>
>>    
>>
>>>I have "backported" this to a cvs checkout of 3.0.2.  It isn't
>>>perfect, but it meets my needs and is probably a good start.
>>>
>>>Is anyone interested in it?
>>>
>>>Is there a maintainer for 3.0.2/3.0.3?
>>>
>>>
>>>
>>>-matt
>>>
>>>Howard M. Lewis Ship (JIRA) wrote:
>>>
>>>      
>>>
>>>>    [ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
>>>>    Howard M. Lewis Ship resolved TAPESTRY-281:
>>>>-------------------------------------------
>>>>
>>>>   Resolution: Fixed
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>asset service has security flaw
>>>>>-------------------------------
>>>>>
>>>>>        Key: TAPESTRY-281
>>>>>        URL: http://issues.apache.org/jira/browse/TAPESTRY-281
>>>>>    Project: Tapestry
>>>>>       Type: Bug
>>>>> Components: Framework
>>>>>   Versions: 3.1
>>>>>Environment: Tomcat 5, JDK 1.4
>>>>>   Reporter: Howard M. Lewis Ship
>>>>>   Assignee: Howard M. Lewis Ship
>>>>>    Fix For: 3.1
>>>>>
>>>>>          
>>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>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
>>
>>
>>    
>>
>
>
>  
>

---------------------------------------------------------------------
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