Bug 974259 (CVE-2013-2175)

Summary: CVE-2013-2175 haproxy: http_get_hdr()/get_ip_from_hdr2() MAX_HDR_HISTORY handling denial of service
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: bleanhar, ccoleman, dmcphers, herrold, jialiu, lmeyer, rohara, security-response-team, tkramer
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-03 05:25:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 974262, 974263, 974265, 974266, 975160    
Bug Blocks: 974261    

Description Kurt Seifried 2013-06-13 19:22:44 UTC
Willy Tarreau (w) reports:

Hi all,

a reproducible crash on latest haproxy snapshots was recently reported,
and could finally be tracked down to a serious bug affecting all versions
since 1.4.4.

The bug is in http_get_hdr() in haproxy 1.5, or get_ip_from_hdr2() in
haproxy 1.4. If a configuration makes use of one of the following functions :

   - hdr_ip(<name>, <value>)  (in 1.4)
   - hdr_*(<name>, <value>)   (in 1.5)

with a negative <value>, then the configuration risks to crash when the
request contains exactly MAX_HDR_HISTORY values for the header <name>.

Note: "source 0.0.0.0 usesrc hdr_ip(<name>)" uses -1 by default for <value>
and is vulnerable as well !

The quick workaround I can suggest before patching is to reject dangerous
requests early using hdr_cnt(<name>), which is available both in 1.4 and 1.5 :

   block if { hdr_cnt(<name>) ge 10 }

Thus, I'm going to issue 1.5-dev19 and 1.4.24 with the following patch applied.
1.5-dev has not received significant updates recently and is of very little
risk when migrating from dev17 or dev18.

The new version will probably be finished during the week-end with an announce
on Monday morning european time. It leaves enough time to finish testing the
last snapshots.

If anyone has any concern with the fix, please discuss it on the list so that
we can find a quick solution together.

I'll request a CVE ID for this bug after the release. If any of the
subscribers has a list of spare CVE IDs, feel free to propose one before
the release, that way I'll update the commit message to report it.

Best regards,
Willy
-

From 20d1c2cb1c6fcfe1f74a79f15573223701903834 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w>
Date: Wed, 12 Jun 2013 22:27:44 +0200
Subject: BUG/CRITICAL: fix a possible crash when using negative header
 occurrences

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.

This bug has been present since the introduction of the negative offset
count in 1.4.4 via commit bce70882. It has been reported by David Torgerson
who offered some debugging traces showing where the crash happened, thus
making it significantly easier to find the bug!

This fix must absolutely be backported to 1.4.

Comment 4 Kurt Seifried 2013-06-17 17:56:23 UTC
This issue is now public:

http://marc.info/?l=haproxy&m=137147915029705&w=2

Comment 5 Kurt Seifried 2013-06-17 18:04:11 UTC
Created haproxy tracking bugs for this issue

Affects: fedora-all [bug 975160]

Comment 6 Fedora Update System 2013-06-28 06:14:28 UTC
haproxy-1.4.24-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2013-06-28 06:16:02 UTC
haproxy-1.4.24-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2013-06-29 18:15:27 UTC
haproxy-1.4.24-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Kurt Seifried 2013-07-23 18:28:54 UTC
Corrected CVSS2 score, I:P -> A:P, typo

Comment 11 Murray McAllister 2013-07-30 09:38:20 UTC
Acknowledgements:

Red Hat would like to thank HAProxy upstream for reporting this issue. Upstream acknowledges David Torgerson as the original reporter.

Comment 12 errata-xmlrpc 2013-07-30 17:00:18 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2013:1120 https://rhn.redhat.com/errata/RHSA-2013-1120.html

Comment 13 errata-xmlrpc 2013-09-04 18:00:03 UTC
This issue has been addressed in following products:

  RHEL 6 Version of OpenShift Enterprise 1.2

Via RHSA-2013:1204 https://rhn.redhat.com/errata/RHSA-2013-1204.html