From ${URL} : 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 @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
haproxy-1.4.24 has just been commited. Feel free to stabilize =net-proxy/haproxy-1.4.24.
(In reply to Christian Ruppert (idl0r) from comment #1) > haproxy-1.4.24 has just been commited. Feel free to stabilize > =net-proxy/haproxy-1.4.24. Thanks, Christian. Arches, please test and mark stable.
amd64 stable
x86 stable
ppc stable
Ready for vote, I vote YES.
YES
This issue was resolved and addressed in GLSA 201307-01 at http://security.gentoo.org/glsa/glsa-201307-01.xml by GLSA coordinator Sean Amoss (ackle).
CVE-2013-2175 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2175): HAProxy 1.4 before 1.4.24 and 1.5 before 1.5-dev19, when configured to use hdr_ip or other "hdr_*" functions with a negative occurrence count, allows remote attackers to cause a denial of service (negative array index usage and crash) via an HTTP header with a certain number of values, related to the MAX_HDR_HISTORY variable.
