hashdos security vulnerability in QueryStringDecoder and possibly other components #141

Closed
trustin opened this Issue Dec 30, 2011 · 2 comments

Comments

Projects
None yet
2 participants
Owner

trustin commented Dec 30, 2011

http://mail-archives.apache.org/mod_mbox/www-announce/201112.mbox/%3C4EFB9800.5010106@apache.org%3E

We could limit the maximum number of decoded parameters in QueryStringDecoder and HTTP Header decoder. We also need to review all components that uses map-ish data structure and limit its max size if they can lead to a security hole.

trustin was assigned Dec 30, 2011

Owner

normanmaurer commented Dec 30, 2011

Yeah.. unfortunally its a public vuln. So we should get a fix out ASAP

@trustin trustin added a commit that referenced this issue Dec 30, 2011

@trustin trustin Issue #141: hashdos security vulnerability in QueryStringDecoder and …
…possibl

* Limited maximum number of parameters to 1024 by default and made the limitation configurable
* QueryStringDecoder is now able to handle an HTTP POST content
* Backported the improvements from master
72a8159

@trustin trustin added a commit that referenced this issue Dec 30, 2011

@trustin trustin Issue #141: hashdos security vulnerability in QueryStringDecoder and …
…possibly other components

* Limited maximum number of parameters to 1024 by default and made the
limitation configurable
* QueryStringDecoder is now able to handle an HTTP POST content
521bf83
Owner

trustin commented Dec 30, 2011

We actually are immune on the header decoder side because we already limit the max size of total header data. The default is 8192, and that means at the worst case there can be only 2048 header entries, and to exploit the vulnerability the attacker should have longer header names, which means the header decoder is immune.

trustin closed this Jan 9, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment