summaryrefslogtreecommitdiff
path: root/debian/patches/CVE-2020-11810.patch
diff options
context:
space:
mode:
authorBernhard Schmidt <berni@debian.org>2021-04-28 16:47:06 +0200
committerBernhard Schmidt <berni@debian.org>2021-04-28 16:47:06 +0200
commitc7528a75539f46a1b23d8c32ec83952fe095ae52 (patch)
tree27184ca8d8d2898ea7ba27a27d83e34db0525c3d /debian/patches/CVE-2020-11810.patch
parenta351f71e82badcc71a2ce881bbb97eccfcebc06b (diff)
Cherry-Pick upstream patches for CVE-2020-11810 and CVE-2020-15078
Closes: #987380
Diffstat (limited to 'debian/patches/CVE-2020-11810.patch')
-rw-r--r--debian/patches/CVE-2020-11810.patch65
1 files changed, 65 insertions, 0 deletions
diff --git a/debian/patches/CVE-2020-11810.patch b/debian/patches/CVE-2020-11810.patch
new file mode 100644
index 0000000..466cf0c
--- /dev/null
+++ b/debian/patches/CVE-2020-11810.patch
@@ -0,0 +1,65 @@
+From 37bc691e7d26ea4eb61a8a434ebd7a9ae76225ab Mon Sep 17 00:00:00 2001
+From: Lev Stipakov <lev@openvpn.net>
+Date: Wed, 15 Apr 2020 10:30:17 +0300
+Subject: [PATCH] Fix illegal client float (CVE-2020-11810)
+
+There is a time frame between allocating peer-id and initializing data
+channel key (which is performed on receiving push request or on async
+push-reply) in which the existing peer-id float checks do not work right.
+
+If a "rogue" data channel packet arrives during that time frame from
+another address and with same peer-id, this would cause client to float
+to that new address. This is because:
+
+ - tls_pre_decrypt() sets packet length to zero if
+ data channel key has not been initialized, which leads to
+
+ - openvpn_decrypt() returns true if packet length is zero,
+ which leads to
+
+ - process_incoming_link_part1() returns true, which
+ calls multi_process_float(), which commits float
+
+Note that problem doesn't happen when data channel key is initialized,
+since in this case openvpn_decrypt() returns false.
+
+The net effect of this behaviour is that the VPN session for the
+"victim client" is broken. Since the "attacker client" does not have
+suitable keys, it can not inject or steal VPN traffic from the other
+session. The time window is small and it can not be used to attack
+a specific client's session, unless some other way is found to make it
+disconnect and reconnect first.
+
+CVE-2020-11810 has been assigned to acknowledge this risk.
+
+Fix illegal float by adding buffer length check ("is this packet still
+considered valid") before calling multi_process_float().
+
+Trac: #1272
+CVE: 2020-11810
+
+Signed-off-by: Lev Stipakov <lev@openvpn.net>
+Acked-by: Arne Schwabe <arne@rfc2549.org>
+Acked-by: Antonio Quartulli <antonio@openvpn.net>
+Acked-by: Gert Doering <gert@greenie.muc.de>
+Message-Id: <20200415073017.22839-1-lstipakov@gmail.com>
+URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19720.html
+Signed-off-by: Gert Doering <gert@greenie.muc.de>
+---
+ src/openvpn/multi.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
+index b42bcec97..056e3dc76 100644
+--- a/src/openvpn/multi.c
++++ b/src/openvpn/multi.c
+@@ -2577,7 +2577,8 @@ multi_process_incoming_link(struct multi_context *m, struct multi_instance *inst
+ orig_buf = c->c2.buf.data;
+ if (process_incoming_link_part1(c, lsi, floated))
+ {
+- if (floated)
++ /* nonzero length means that we have a valid, decrypted packed */
++ if (floated && c->c2.buf.len > 0)
+ {
+ multi_process_float(m, m->pending);
+ }