]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/CRITICAL: http: don't update msg->sov once data start to leave the buffer
authorWilly Tarreau <w@1wt.eu>
Mon, 1 Sep 2014 18:35:55 +0000 (20:35 +0200)
committerWilly Tarreau <w@1wt.eu>
Tue, 2 Sep 2014 14:48:54 +0000 (16:48 +0200)
commit9dc1c61c433a30359b14bb099ddae7d154df923e
treef6eff1142b4d4ab013dc74ec3b98e39de7f35a92
parent1a0191d2ff83d1ce7458ebf8b54640ab0a8acf23
BUG/CRITICAL: http: don't update msg->sov once data start to leave the buffer

Commit bb2e669 ("BUG/MAJOR: http: correctly rewind the request body
after start of forwarding") was incorrect/incomplete. It used to rely on
CF_READ_ATTACHED to stop updating msg->sov once data start to leave the
buffer, but this is unreliable because since commit a6eebb3 ("[BUG]
session: clear BF_READ_ATTACHED before next I/O") merged in 1.5-dev1,
this flag is only ephemeral and is cleared once all analysers have
seen it. So we can start updating msg->sov again each time we pass
through this place with new data. With a sufficiently large amount of
data, it is possible to make msg->sov wrap and validate the if()
condition at the top, causing the buffer to advance by about 2GB and
crash the process.

Note that the offset cannot be controlled by the attacker because it is
a sum of millions of small random sizes depending on how many bytes were
read by the server and how many were left in the buffer, only because
of the speed difference between reading and writing. Also, nothing is
written, the invalid pointer resulting from this operation is only read.

Many thanks to James Dempsey for reporting this bug and to Chris Forbes for
narrowing down the faulty area enough to make its root cause analysable.

This fix must be backported to haproxy 1.5.
include/types/channel.h
src/proto_http.c
src/stream_interface.c