Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • aports aports
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 725
    • Issues 725
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 383
    • Merge requests 383
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • alpine
  • aportsaports
  • Issues
  • #2114

Closed
Open
Created Jun 21, 2013 by Natanael Copa@ncopaOwner

[v2.7] CVE-2013-2175 : haproxy may crash when using header occurrences relative to the tail

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(), which is available both in 1.4 and 1.5 :

block if { hdr_cnt() 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 occurence number :

- hdr_ip(, ) (in 1.4)

  • hdr_*(, ) (in 1.5)

It also affects “source” statements involving “hdr_ip()” since that
statement implicitly uses –1 for :

- source 0.0.0.0 usesrc hdr_ip()

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

(from redmine: issue id 2114, created on 2013-06-21, closed on 2013-07-03)

  • Relations:
    • parent #2098 (closed)
  • Changesets:
    • Revision d2207b3c by Natanael Copa on 2013-06-21T13:37:42Z:
main/haproxy: security upgrade to 1.4.24 (CVE-2013-2175)

fixes #2114
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking