Bug 947581 (CVE-2013-1912) - CVE-2013-1912 haproxy: rewrite rules flaw can lead to arbitrary code execution
Summary: CVE-2013-1912 haproxy: rewrite rules flaw can lead to arbitrary code execution
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-1912
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 947697 947699 947700 947701 947702 947703
Blocks: 948042
TreeView+ depends on / blocked
 
Reported: 2013-04-02 19:04 UTC by Kurt Seifried
Modified: 2023-05-12 23:20 UTC (History)
9 users (show)

Fixed In Version: haproxy 1.4.23, haproxy 1.5-dev18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-28 19:47:52 UTC
Embargoed:


Attachments (Terms of Use)
haproxy-CVE-2013-1912-request-buffers.patch (1.80 KB, patch)
2013-04-03 03:44 UTC, Kurt Seifried
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0729 0 normal SHIPPED_LIVE Moderate: haproxy security update 2013-04-09 22:11:38 UTC
Red Hat Product Errata RHSA-2013:0868 0 normal SHIPPED_LIVE Moderate: haproxy security update 2013-05-28 21:28:20 UTC

Description Kurt Seifried 2013-04-02 19:04:22 UTC
Willy Tarreau reports:

we've discovered a vulnerability in haproxy when we use 'tcp-request
content rules which make use of some HTTP ACLs, combined with
keep-alive and request rewrite rules. A client making use of
pipelining could cause the rewrite rules to write past the buffer's
end because the reserved space is missing.

Comment 1 Kurt Seifried 2013-04-03 03:39:09 UTC
Willy Tarreau reports:

Hi,

Yves Lafon from the W3C reported some random crashes of haproxy with an
advanced configuration, that we finally considered was a security issue
as it could remotely be triggered.


--- summary ---

Configurations at risk are those which combine use of HTTP keywords in
TCP content inspection rules, client-side keep-alive, header rewriting
rules and which receive pipelined requests. These configurations may be
remotely crashed when run with haproxy 1.4 up to and including 1.4.22
or development versions up to and including 1.5-dev17. Versions 1.4.23
and 1.5-dev18 are safe.


--- quick workaround ---

Disable TCP content inspection, or disable HTTP keep-alive by inserting
"option forceclose" in the affected frontends.


--- details ---

During normal HTTP request processing, request buffers are realigned if
there are less than global.maxrewrite bytes available after them, in
order to leave enough room for rewriting headers after the request. This
is done in http_wait_for_request().
    
However, if some HTTP inspection happens during a "tcp-request content"
rule, this realignment is not performed. In theory this is not a problem
because empty buffers are always aligned and TCP inspection happens at
the beginning of a connection. But with HTTP keep-alive, it also happens
at the beginning of each subsequent request. So if a second request was
pipelined by the client before the first one had a chance to be forwarded,
the second request will not be realigned. Then, http_wait_for_request()
will not perform such a realignment either because the request was
already parsed and marked as such. The consequence of this, is that the
rewrite of a sufficient number of such pipelined, unaligned requests may
leave less room past the request been processed than the configured
reserve, which can lead to a buffer overflow if request processing appends
some data past the end of the buffer.
    
A number of conditions are required for the bug to be triggered :
   - HTTP keep-alive must be enabled ;
   - HTTP inspection in TCP rules must be used ;
   - some request appending rules are needed (reqadd, x-forwarded-for)
   - since empty buffers are always realigned, the client must pipeline
     enough requests so that the buffer always contains something till
     the point where there is no more room for rewriting.
    
While such a configuration is quite unlikely to be met (which is
confirmed by the bug's lifetime), a few people do use these features
together for very specific usages. And more importantly, writing such
a configuration and the request to attack it is trivial.
    
A quick workaround consists in forcing keep-alive off by adding
"option httpclose" or "option forceclose" in the frontend. Alternatively,
disabling HTTP-based TCP inspection rules enough if the application
supports it.
    
At first glance, this bug does not look like it could lead to remote code
execution, as the overflowing part is controlled by the configuration and
not by the user. But some deeper analysis should be performed to confirm
this. And anyway, corrupting the process' memory and crashing it is quite
trivial.
    
Special thanks go to Yves Lafon from the W3C who reported this bug and
deployed significant efforts to collect the relevant data needed to
understand it in less than one week, and to Ryan O'Hara from Red Hat
for providing me with a CVE number.
    
CVE-2013-1912 was assigned to this issue.

--- links ---
1.4-stable patch for version <= 1.4.22 :
http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=dc80672211
1.4.23 source code: 
http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.23.tar.gz

1.5-dev patch for versions <= 1.5-dev17 :
http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=aae75e3279
1.5-dev18 source code:
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev18.tar.gz

Please check with your distro vendor for packaged updates.
--

Thanks,
Willy Tarreau

Source information:
http://www.openwall.com/lists/oss-security/2013/04/03/1

Comment 2 Kurt Seifried 2013-04-03 03:41:15 UTC
Created haproxy tracking bugs for this issue

Affects: fedora-all [bug 947697]

Comment 3 Kurt Seifried 2013-04-03 03:44:59 UTC
Created attachment 731037 [details]
haproxy-CVE-2013-1912-request-buffers.patch

Comment 4 Kurt Seifried 2013-04-03 03:57:29 UTC
Created haproxy tracking bugs for this issue

Affects: epel-5 [bug 947699]

Comment 8 Tomas Hoger 2013-04-03 09:09:22 UTC
(In reply to comment #1)
> Willy Tarreau reports:

Reported via: http://seclists.org/oss-sec/2013/q2/3

Comment 9 Murray McAllister 2013-04-09 10:03:30 UTC
Acknowledgements:

Red Hat would like to thank Willy Tarreau of HAProxy upstream for reporting this issue. Upstream acknowledges Yves Lafon from the W3C as the original reporter.

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

  RHEL 6 Version of OpenShift Enterprise

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

Comment 11 Fedora Update System 2013-04-26 23:59:43 UTC
haproxy-1.4.23-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 12 Fedora Update System 2013-04-27 00:14:25 UTC
haproxy-1.4.23-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 13 Fedora Update System 2013-04-27 03:05:55 UTC
haproxy-1.4.23-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 errata-xmlrpc 2013-05-28 17:31:47 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

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


Note You need to log in before you can comment on or make changes to this bug.