[
https://issues.apache.org/jira/browse/XERCESJ-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörn Horstmann updated XERCESJ-1547:
------------------------------------
Description:
The talk "Effective DoS attacks against Web Application Plattforms - #hashDoS"
given at the "chaos communication congress (28c3)" last week showed that many
web applications are vulnerable to hash collisions in POST parameters.
Descriptions of the problem can be found at
https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/
and http://permalink.gmane.org/gmane.comp.security.full-disclosure/83694
I wanted to determine if xerces would als be affected by hash collision
attacks, so I prepared a document of 2MB consisting of a single root element
and about 125000 attributes having the same java.lang.String#hashCode. Parsing
this document with xerces 2.9.1 on an i7 2620 notebook took about 8 minutes
with one core at 100% cpu usage. According to the Netbeans profiler 56% of that
was spent inside org.apache.xerces.util.SymbolTable#addSymbol and another 42%
in org.apache.xerces.util.XMLAttributesImpl#checkDuplicatesNS.
This behaviour can also be triggered by webservice calls and so is a serious
problem. The workaround in Tomcat was to impose a limit on the maximum number
of parameters in a post request, perhaps a similar setting could be introduced,
configurable by a JAXP parser feature.
I can provide the xml file showcasing this problem but I would prefer to not
post it to a public bug tracker.
was:
The talk "Effective DoS attacks against Web Application Plattforms - #hashDoS"
given at the "chaos communication congress (28c3)" last week showed that many
web applications are vulnerable to hash collisions in POST parameters.
Descriptions of the problem can be found at
https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/
and http://permalink.gmane.org/gmane.comp.security.full-disclosure/83694
I wanted to determine if xerces would als be affected by hash collision
attacks, so I prepared a document of 2MB consisting of a single root element
and about 125000 attributes having the same java.lang.String#hashCode. Parsing
this document with xerces 2.9.1 on an i7 2620 notebook took about 8 minutes
with one core at 100% cpu usage. According to the Netbeans profiler 56% of that
was spent inside org.apache.xerces.util.SymbolTable#addSymbol and another 42%
in org.apache.xerces.util.XMLAttributesImpl#checkDuplicatesNS.
This behaviour can also be triggered by webservice calls and so is a serious
problem. The workaround in Tomcat was to impose a limit on the maximum number
of parameters in a post request, perhaps a similar setting could be introduced,
configurable by a JAXP parser feature.
> Huge CPU comsumption when parsing elements with attributes hashing to the
> same value
> ------------------------------------------------------------------------------------
>
> Key: XERCESJ-1547
> URL: https://issues.apache.org/jira/browse/XERCESJ-1547
> Project: Xerces2-J
> Issue Type: New Feature
> Components: JAXP (javax.xml.parsers)
> Affects Versions: 2.9.1
> Reporter: Jörn Horstmann
> Labels: perfomance, security
>
> The talk "Effective DoS attacks against Web Application Plattforms -
> #hashDoS" given at the "chaos communication congress (28c3)" last week showed
> that many web applications are vulnerable to hash collisions in POST
> parameters. Descriptions of the problem can be found at
> https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/
> and http://permalink.gmane.org/gmane.comp.security.full-disclosure/83694
> I wanted to determine if xerces would als be affected by hash collision
> attacks, so I prepared a document of 2MB consisting of a single root element
> and about 125000 attributes having the same java.lang.String#hashCode.
> Parsing this document with xerces 2.9.1 on an i7 2620 notebook took about 8
> minutes with one core at 100% cpu usage. According to the Netbeans profiler
> 56% of that was spent inside org.apache.xerces.util.SymbolTable#addSymbol and
> another 42% in org.apache.xerces.util.XMLAttributesImpl#checkDuplicatesNS.
> This behaviour can also be triggered by webservice calls and so is a serious
> problem. The workaround in Tomcat was to impose a limit on the maximum number
> of parameters in a post request, perhaps a similar setting could be
> introduced, configurable by a JAXP parser feature.
> I can provide the xml file showcasing this problem but I would prefer to not
> post it to a public bug tracker.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
