Hide Forgot
A malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel.
Public via: https://seclists.org/oss-sec/2019/q4/122 https://www.openwall.com/lists/oss-security/2019/12/05/3 https://www.zdnet.com/article/new-vulnerability-lets-attackers-sniff-or-hijack-vpn-connections/ https://www.bleepingcomputer.com/news/security/new-linux-vulnerability-lets-attackers-hijack-vpn-connections/
Created ike tracking bugs for this issue: Affects: epel-6 [bug 1780526] Affects: epel-8 [bug 1780527] Affects: fedora-all [bug 1780525] Created openvpn tracking bugs for this issue: Affects: epel-all [bug 1780524] Affects: fedora-all [bug 1780523]
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.
External References: https://openvpn.net/security-advisory/no-flaws-found-in-openvpn-software/
To quote the original message to oss-sec, "This vulnerability works against OpenVPN, WireGuard, and IKEv2/IPSec" Are the implementations of IKEv2 and IPSec in RHEL vulnerable based on the systemd configuration? What about libreswan?
(In reply to Steve Susbauer from comment #13) > To quote the original message to oss-sec, "This vulnerability works against > OpenVPN, WireGuard, and IKEv2/IPSec" > > Are the implementations of IKEv2 and IPSec in RHEL vulnerable based on the > systemd configuration? What about libreswan? I believe this issue not strictly tied to any specific VPN solution, the paper just used VPN as one potential attack vector. This issue goes deeper into how the network stack in the kernel works in general (related to the host model [1]) and could typically work against any network interface. My personal opinion about this research paper and CVE is that it is not describing the issue clearly enough and instead points fingers at several specific VPN solutions. And then most media goes wild while not fully understanding the paper, but since it mentions several VPN solutions they ignore the finer details and claims in bold headlines that "VPN solution FOOBAR is broken". What is also an important detail, this paper proposes three potential mitigations; only one of them would be applicable for the VPN implementations - and if I understood some replies, IPSec even has this feature proposed available today but is disabled by default (and I don't believe it is disabled by default for a security reason, but more a performance reason). [1] https://en.wikipedia.org/wiki/Host_model
The Linux XFRM IPsec implementation provides hooks that are not bypassed by any kind of routing. It ensures packets that should have been encrypted are not received plaintext, and drops those that are. So I strongly suspect that our IKE/IPsec solution (libreswan + Linux kernel) is not vulnerable to this, irrespective of how the init system or administrator setup the rp_filter options. however, I am still in the process of writing up test cases that confirm my expectation before I do a write up on this.
Statement: This issue did not affect Red Hat Enterprise Linux 5, 6, 7, and 8 as openvpn package is currently not provided in any of our supported products.