diff --git a/.gitignore b/.gitignore index ec3a304..b3c4ea2 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -SOURCES/haproxy-1.8.15.tar.gz +SOURCES/haproxy-1.8.23.tar.gz diff --git a/.haproxy.metadata b/.haproxy.metadata index 8bda435..3d2a7e7 100644 --- a/.haproxy.metadata +++ b/.haproxy.metadata @@ -1 +1 @@ -ed7dfe5c7fc39fbb3b54e981eb709fd8bcd87042 SOURCES/haproxy-1.8.15.tar.gz +c1b6c1d4d5de55bcad874a0a7a02a94db5638b1f SOURCES/haproxy-1.8.23.tar.gz diff --git a/SOURCES/bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch b/SOURCES/bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch deleted file mode 100644 index 24ed204..0000000 --- a/SOURCES/bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch +++ /dev/null @@ -1,51 +0,0 @@ -From 4e372dc350be5c72b88546bf03392a5793cea179 Mon Sep 17 00:00:00 2001 -From: Willy Tarreau -Date: Sun, 29 Mar 2020 08:53:31 +0200 -Subject: BUG/CRITICAL: hpack: never index a header into the headroom after - wrapping - -The HPACK header table is implemented as a wrapping list inside a contigous -area. Headers names and values are stored from right to left while indexes -are stored from left to right. When there's no more room to store a new one, -we wrap to the right again, or possibly defragment it if needed. The condition -do use the right part (called tailroom) or the left part (called headroom) -depends on the location of the last inserted header. After wrapping happens, -the code forces to stick to tailroom by pretending there's no more headroom, -so that the size fit test always fails. The problem is that nothing prevents -from storing a header with an empty name and empty value, resulting in a -total size of zero bytes, which satisfies the condition to use the headroom. -Doing this in a wrapped buffer results in changing the "front" header index -and causing miscalculations on the available size and the addresses of the -next headers. This may even allow to overwrite some parts of the index, -opening the possibility to perform arbitrary writes into a 32-bit relative -address space. - -This patch fixes the issue by making sure the headroom is considered only -when the buffer does not wrap, instead of relying on the zero size. This -must be backported to all versions supporting H2, which is as far as 1.8. - -Many thanks to Felix Wilhelm of Google Project Zero for responsibly -reporting this problem with a reproducer and a detailed analysis. ---- - src/hpack-tbl.c | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/src/hpack-tbl.c b/src/hpack-tbl.c -index 70d7f35834..727ff7a17b 100644 ---- a/src/hpack-tbl.c -+++ b/src/hpack-tbl.c -@@ -346,9 +346,9 @@ int hpack_dht_insert(struct hpack_dht *dht, struct ist name, struct ist value) - * room left in the tail to suit the protocol, but tests show that in - * practice it almost never happens in other situations so the extra - * test is useless and we simply fill the headroom as long as it's -- * available. -+ * available and we don't wrap. - */ -- if (headroom >= name.len + value.len) { -+ if (prev == dht->front && headroom >= name.len + value.len) { - /* install upfront and update ->front */ - dht->dte[head].addr = dht->dte[dht->front].addr - (name.len + value.len); - dht->front = head; --- -2.20.1 - diff --git a/SOURCES/bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch b/SOURCES/bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch new file mode 100644 index 0000000..24ed204 --- /dev/null +++ b/SOURCES/bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch @@ -0,0 +1,51 @@ +From 4e372dc350be5c72b88546bf03392a5793cea179 Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Sun, 29 Mar 2020 08:53:31 +0200 +Subject: BUG/CRITICAL: hpack: never index a header into the headroom after + wrapping + +The HPACK header table is implemented as a wrapping list inside a contigous +area. Headers names and values are stored from right to left while indexes +are stored from left to right. When there's no more room to store a new one, +we wrap to the right again, or possibly defragment it if needed. The condition +do use the right part (called tailroom) or the left part (called headroom) +depends on the location of the last inserted header. After wrapping happens, +the code forces to stick to tailroom by pretending there's no more headroom, +so that the size fit test always fails. The problem is that nothing prevents +from storing a header with an empty name and empty value, resulting in a +total size of zero bytes, which satisfies the condition to use the headroom. +Doing this in a wrapped buffer results in changing the "front" header index +and causing miscalculations on the available size and the addresses of the +next headers. This may even allow to overwrite some parts of the index, +opening the possibility to perform arbitrary writes into a 32-bit relative +address space. + +This patch fixes the issue by making sure the headroom is considered only +when the buffer does not wrap, instead of relying on the zero size. This +must be backported to all versions supporting H2, which is as far as 1.8. + +Many thanks to Felix Wilhelm of Google Project Zero for responsibly +reporting this problem with a reproducer and a detailed analysis. +--- + src/hpack-tbl.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/src/hpack-tbl.c b/src/hpack-tbl.c +index 70d7f35834..727ff7a17b 100644 +--- a/src/hpack-tbl.c ++++ b/src/hpack-tbl.c +@@ -346,9 +346,9 @@ int hpack_dht_insert(struct hpack_dht *dht, struct ist name, struct ist value) + * room left in the tail to suit the protocol, but tests show that in + * practice it almost never happens in other situations so the extra + * test is useless and we simply fill the headroom as long as it's +- * available. ++ * available and we don't wrap. + */ +- if (headroom >= name.len + value.len) { ++ if (prev == dht->front && headroom >= name.len + value.len) { + /* install upfront and update ->front */ + dht->dte[head].addr = dht->dte[dht->front].addr - (name.len + value.len); + dht->front = head; +-- +2.20.1 + diff --git a/SOURCES/haproxy.service b/SOURCES/haproxy.service index b32d00c..2b3a35e 100644 --- a/SOURCES/haproxy.service +++ b/SOURCES/haproxy.service @@ -8,6 +8,7 @@ ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE ExecReload=/usr/sbin/haproxy -f $CONFIG -c -q ExecReload=/bin/kill -USR2 $MAINPID +SuccessExitStatus=143 KillMode=mixed Type=notify diff --git a/SPECS/haproxy.spec b/SPECS/haproxy.spec index c3efda6..fe10158 100644 --- a/SPECS/haproxy.spec +++ b/SPECS/haproxy.spec @@ -7,8 +7,8 @@ %global _hardened_build 1 Name: haproxy -Version: 1.8.15 -Release: 6%{?dist}.1 +Version: 1.8.23 +Release: 3%{?dist} Summary: HAProxy reverse proxy for high availability environments Group: System Environment/Daemons @@ -23,7 +23,7 @@ Source4: %{name}.sysconfig Source5: halog.1 Patch0: bz1664533-fix-handling-priority-flag-HTTP2-decoder.patch -Patch1: bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch +Patch1: bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch BuildRequires: lua-devel BuildRequires: pcre-devel @@ -140,8 +140,14 @@ exit 0 %{_mandir}/man1/* %changelog -* Wed Apr 01 2020 Ryan O'Hara - 1.8.15-6.1 -- - Fix hapack zero byte input causing overwrite (CVE-2020-11100, #1819518) +* Wed Apr 01 2020 Ryan O'Hara - 1.8.23-3 +- Fix hapack zero byte input causing overwrite (CVE-2020-11100, #1819519) + +* Fri Dec 13 2019 Ryan O'Hara - 1.8.23-2 +- Consider exist status 143 as success (#1778844) + +* Mon Dec 02 2019 Ryan O'Hara - 1.8.23-1 +- Update to 1.8.23 (#1774745) * Fri Jul 19 2019 Ryan O'Hara - 1.8.15-6 - Add gating tests (#1682106)