From owner-svn-ports-all@freebsd.org Thu Apr 16 09:48:23 2020 Return-Path: Delivered-To: svn-ports-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F325B2B8206; Thu, 16 Apr 2020 09:48:23 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492vYM69Ngz4H8B; Thu, 16 Apr 2020 09:48:23 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B66226CA6; Thu, 16 Apr 2020 09:48:23 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 03G9mNc3099592; Thu, 16 Apr 2020 09:48:23 GMT (envelope-from mandree@FreeBSD.org) Received: (from mandree@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 03G9mNEx099590; Thu, 16 Apr 2020 09:48:23 GMT (envelope-from mandree@FreeBSD.org) Message-Id: <202004160948.03G9mNEx099590@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: mandree set sender to mandree@FreeBSD.org using -f From: Matthias Andree Date: Thu, 16 Apr 2020 09:48:23 +0000 (UTC) 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 X-SVN-Group: ports-branches X-SVN-Commit-Author: mandree X-SVN-Commit-Paths: in branches/2020Q2/security/openvpn: . files X-SVN-Commit-Revision: 531838 X-SVN-Commit-Repository: ports MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 09:48:24 -0000 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 +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 + Acked-by: Arne Schwabe + Acked-by: Antonio Quartulli + Acked-by: Gert Doering + 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 + (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); + }