Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Apr 2020 09:48:23 +0000 (UTC)
From:      Matthias Andree <mandree@FreeBSD.org>
To:        ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-branches@freebsd.org
Subject:   svn commit: r531838 - in branches/2020Q2/security/openvpn: . files
Message-ID:  <202004160948.03G9mNEx099590@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: mandree
Date: Thu Apr 16 09:48:23 2020
New Revision: 531838
URL: https://svnweb.freebsd.org/changeset/ports/531838

Log:
  MFH: r531837
  
  security/openvpn: 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.
  
  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.
  
  This fix is inherited by the openvpn-mbedtls slave port.
  
  Blanket "Backport of security and reliability fixes which only result in
  PORTREVISION bumps and no changes to enabled features. for example, adding
  a patch fixing a buffer overflow."
  
  Obtained from:	Lev Stipakov (OpenVPN)
  Security:	CVE-2020-11810
  Security:	8604121c-7fc2-11ea-bcac-7781e90b0c8f
  
  Approved by:	ports-secteam@ (blanket security/reliability fix)

Added:
  branches/2020Q2/security/openvpn/files/patch-CVE-2020-11810
     - copied unchanged from r531837, head/security/openvpn/files/patch-CVE-2020-11810
Modified:
  branches/2020Q2/security/openvpn/Makefile
Directory Properties:
  branches/2020Q2/   (props changed)

Modified: branches/2020Q2/security/openvpn/Makefile
==============================================================================
--- branches/2020Q2/security/openvpn/Makefile	Thu Apr 16 09:46:15 2020	(r531837)
+++ branches/2020Q2/security/openvpn/Makefile	Thu Apr 16 09:48:23 2020	(r531838)
@@ -5,7 +5,7 @@ PORTNAME=		openvpn
 DISTVERSION=		2.4.8
 # FIXME XXX check if 2.4.9 still needs ASYNC_PUSH_LIBS, see
 # https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244286#c6 and #c7
-PORTREVISION?=		2
+PORTREVISION?=		3
 CATEGORIES=		security net net-vpn
 MASTER_SITES=		https://swupdate.openvpn.org/community/releases/ \
 			https://build.openvpn.net/downloads/releases/

Copied: branches/2020Q2/security/openvpn/files/patch-CVE-2020-11810 (from r531837, head/security/openvpn/files/patch-CVE-2020-11810)
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ branches/2020Q2/security/openvpn/files/patch-CVE-2020-11810	Thu Apr 16 09:48:23 2020	(r531838, copy of r531837, head/security/openvpn/files/patch-CVE-2020-11810)
@@ -0,0 +1,64 @@
+commit f7b318f811bb43c0d3aa7f337ec6242ed2c33881
+Author: Lev Stipakov <lev@openvpn.net>
+Date:   Wed Apr 15 10:30:17 2020 +0300
+
+    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>
+    (cherry picked from commit 37bc691e7d26ea4eb61a8a434ebd7a9ae76225ab)
+
+diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
+index 58607730..c8c9a40e 100644
+--- ./src/openvpn/multi.c~
++++ ./src/openvpn/multi.c
+@@ -2562,7 +2562,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);
+                 }



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202004160948.03G9mNEx099590>