Bug 1169925 - (CVE-2020-11810) VUL-1: CVE-2020-11810: openvpn: race condition between allocating peer-id and initializing data channel key
(CVE-2020-11810)
VUL-1: CVE-2020-11810: openvpn: race condition between allocating peer-id and...
Status: IN_PROGRESS
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P4 - Low : Minor
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/257995/
maint:planned:update CVSSv3.1:SUSE:C...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-20 14:25 UTC by Alexandros Toptsoglou
Modified: 2021-05-15 19:17 UTC (History)
2 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandros Toptsoglou 2020-04-20 14:25:19 UTC
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


References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11810
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19720.html
https://github.com/OpenVPN/openvpn/commit/37bc691e7d26ea4eb61a8a434ebd7a9ae76225ab
Comment 1 Alexandros Toptsoglou 2020-04-20 14:26:27 UTC
It seems only versions from 2.4.0 and on are affected. Based on this SLE15 is tracked as affected.
Comment 3 Swamp Workflow Management 2021-05-12 13:28:14 UTC
SUSE-SU-2021:1577-1: An update that fixes three vulnerabilities is now available.

Category: security (moderate)
Bug References: 1085803,1169925,1185279
CVE References: CVE-2018-7544,CVE-2020-11810,CVE-2020-15078
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    openvpn-2.4.3-5.7.1
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    openvpn-2.4.3-5.7.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 4 Swamp Workflow Management 2021-05-15 19:17:59 UTC
openSUSE-SU-2021:0734-1: An update that fixes three vulnerabilities is now available.

Category: security (moderate)
Bug References: 1085803,1169925,1185279
CVE References: CVE-2018-7544,CVE-2020-11810,CVE-2020-15078
JIRA References: 
Sources used:
openSUSE Leap 15.2 (src):    openvpn-2.4.3-lp152.6.3.1