From 2557b9fbbfdef86c25442963f1da879ed1a61576 Mon Sep 17 00:00:00 2001 From: cuibb1 <95227821@qq.com> Date: Fri, 15 May 2020 16:58:05 +0800 Subject: [PATCH 1/2] fix CVE-2020-11100 --- CVE-2020-11100.patch | 52 ++++++++++++++++++++++++++++++++++++++++++++ haproxy.spec | 9 +++++++- 2 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 CVE-2020-11100.patch diff --git a/CVE-2020-11100.patch b/CVE-2020-11100.patch new file mode 100644 index 0000000..a2468a4 --- /dev/null +++ b/CVE-2020-11100.patch @@ -0,0 +1,52 @@ +From 5dfc5d5cd0d2128d77253ead3acf03a421ab5b88 Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Sun, 29 Mar 2020 08:53:31 +0200 +Subject: [PATCH 1/1] 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. +CVE-2020-11100 was assigned to this issue. +--- + 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 70d7f35..727ff7a 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; +-- +1.7.10.4 + diff --git a/haproxy.spec b/haproxy.spec index a579c46..6aedee8 100644 --- a/haproxy.spec +++ b/haproxy.spec @@ -5,7 +5,7 @@ Name: haproxy Version: 1.8.14 -Release: 4 +Release: 5 Summary: The Reliable, High Performance TCP/HTTP Load Balancer License: GPLv2+ @@ -19,6 +19,7 @@ Source4: %{name}.sysconfig Patch6000: CVE-2018-20615-BUG-CRITICAL-mux-h2-re-check-the-frame-length-when-P.patch Patch6001: CVE-2018-20103.patch Patch6002: CVE-2018-20102.patch +Patch6003: CVE-2020-11100.patch BuildRequires: gcc lua-devel pcre-devel zlib-devel openssl-devel systemd-devel systemd-units Requires(pre): shadow-utils @@ -125,5 +126,11 @@ exit 0 %{_mandir}/man1/* %changelog +* Thu May 7 2020 cuibaobao - 1.8.14-5 +- Type:cves +- ID: CVE-2020-11100 +- SUG:restart +- DESC: fix CVE-2020-11100 + * Wed Dec 4 2019 openEuler Buildteam - 1.8.14-4 - Package init -- Gitee From dc5afc89fb18a0867c2f0c8a4fabe0b73a95e605 Mon Sep 17 00:00:00 2001 From: small_leek Date: Sat, 16 May 2020 14:17:43 +0800 Subject: [PATCH 2/2] =?UTF-8?q?=E5=9B=9E=E9=80=80=20'Pull=20Request=20!5?= =?UTF-8?q?=20:=20fix=20cve-2020-11100'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CVE-2020-11100.patch | 52 -------------------------------------------- haproxy.spec | 9 +------- 2 files changed, 1 insertion(+), 60 deletions(-) delete mode 100644 CVE-2020-11100.patch diff --git a/CVE-2020-11100.patch b/CVE-2020-11100.patch deleted file mode 100644 index a2468a4..0000000 --- a/CVE-2020-11100.patch +++ /dev/null @@ -1,52 +0,0 @@ -From 5dfc5d5cd0d2128d77253ead3acf03a421ab5b88 Mon Sep 17 00:00:00 2001 -From: Willy Tarreau -Date: Sun, 29 Mar 2020 08:53:31 +0200 -Subject: [PATCH 1/1] 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. -CVE-2020-11100 was assigned to this issue. ---- - 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 70d7f35..727ff7a 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; --- -1.7.10.4 - diff --git a/haproxy.spec b/haproxy.spec index 6aedee8..a579c46 100644 --- a/haproxy.spec +++ b/haproxy.spec @@ -5,7 +5,7 @@ Name: haproxy Version: 1.8.14 -Release: 5 +Release: 4 Summary: The Reliable, High Performance TCP/HTTP Load Balancer License: GPLv2+ @@ -19,7 +19,6 @@ Source4: %{name}.sysconfig Patch6000: CVE-2018-20615-BUG-CRITICAL-mux-h2-re-check-the-frame-length-when-P.patch Patch6001: CVE-2018-20103.patch Patch6002: CVE-2018-20102.patch -Patch6003: CVE-2020-11100.patch BuildRequires: gcc lua-devel pcre-devel zlib-devel openssl-devel systemd-devel systemd-units Requires(pre): shadow-utils @@ -126,11 +125,5 @@ exit 0 %{_mandir}/man1/* %changelog -* Thu May 7 2020 cuibaobao - 1.8.14-5 -- Type:cves -- ID: CVE-2020-11100 -- SUG:restart -- DESC: fix CVE-2020-11100 - * Wed Dec 4 2019 openEuler Buildteam - 1.8.14-4 - Package init -- Gitee