haproxy DoS when using header occurrences relative to the tail

2013.06.18
Risk: Medium
Local: No
Remote: Yes
CWE: N/A


CVSS Base Score: 5/10
Impact Subscore: 2.9/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: None
Integrity impact: None
Availability impact: Partial

David Torgerson reported an haproxy crash with enough traces to diagnose the cause as being related to the use of a negative occurrence number in a header extraction, which is used to extract an entry starting from the last occurrence. --- summary --- Configurations at risk are those which make use of "hdr_ip(name,-1)" (in 1.4) or any hdr_* variant with a negative occurrence count in 1.5, or the "usesrc hdr_ip(name)" statement in both 1.4 and 1.5. These configurations may be crashed when run with haproxy 1.4.4 to 1.4.23 or development versions up to and including 1.5-dev18. Versions 1.4.24 and 1.5-dev19 are safe. --- quick workaround --- A workaround consists in rejecting dangerous requests early using hdr_cnt(<name>), which is available both in 1.4 and 1.5 : block if { hdr_cnt(<name>) ge 10 } --- details --- When a config makes use of hdr_ip(x-forwarded-for,-1) or any such thing involving a negative occurrence count, the header is still parsed in the order it appears, and an array of up to MAX_HDR_HISTORY entries is created. When more entries are used, the entries simply wrap and continue this way. A problem happens when the incoming header field count exactly divides MAX_HDR_HISTORY, because the computation removes the number of requested occurrences from the count, but does not care about the risk of wrapping with a negative number. Thus we can dereference the array with a negative number and randomly crash the process. The bug is located in http_get_hdr() in haproxy 1.5, and get_ip_from_hdr2() in haproxy 1.4. It affects configurations making use of one of the following functions with a negative <value> occurence number : - hdr_ip(<name>, <value>) (in 1.4) - hdr_*(<name>, <value>) (in 1.5) It also affects "source" statements involving "hdr_ip(<name>)" since that statement implicitly uses -1 for <value> : - source 0.0.0.0 usesrc hdr_ip(<name>) This bug has been present since the introduction of the negative offset count in 1.4.4 via commit bce70882. CVE-2013-2175 was assigned to this bug. Special thanks to David Torgerson who provided a significant number of traces, and to Ryan O'Hara from Red Hat for providing a CVE id. --- links --- 1.4-stable patch for version <= 1.4.23 : http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=f534af74ed 1.4.24 source code: http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz 1.5-dev patch for versions <= 1.5-dev18 : http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b 1.5-dev19 source code: http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev19.tar.gz Please check with your distro vendor for packaged updates. Thanks, Willy Tarreau

References:

http://seclists.org/oss-sec/2013/q2/581


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top