Bugzilla – Bug 1158670
VUL-0: CVE-2019-14899: possibility of data injection in the TCP stream which allows hijacking of active connections inside the VPN tunnel
Last modified: 2024-05-22 14:27:45 UTC
CVE-2019-14899 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. References: https://bugzilla.redhat.com/show_bug.cgi?id=1774905 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 http://seclists.org/oss-sec/2019/q4/122
if the result of cat /proc/sys/net/ipv4/conf/all/rp_filter results in 1 (=strict mode) The attack is mitiggated, according to [1] [1] http://seclists.org/oss-sec/2019/q4/122
(In reply to Alexandros Toptsoglou from comment #1) > if the result of > cat /proc/sys/net/ipv4/conf/all/rp_filter > > results in 1 (=strict mode) > > The attack is mitiggated, according to [1] > > [1] http://seclists.org/oss-sec/2019/q4/122 This is the default configuration for SLE products
Resolving smash.suse.de (smash.suse.de)... failed: Name or service not known Sorry. I'm an openSUSE user. How might/does this affect me?
(In reply to Dave Howorth from comment #3) > Resolving smash.suse.de (smash.suse.de)... failed: Name or service not known > > Sorry. I'm an openSUSE user. How might/does this affect me? Hi Dave, Smash is not available to user's outside SUSE. So it is normal that you cannot visit it.
Here is the upstream response to this CVE: https://openvpn.net/security-advisory/no-flaws-found-in-openvpn-software/ --- snip --- “It doesn't appear to be a flaw in the OpenVPN software, but a flaw in the configuration of the operating system itself. The issue is more in how the operating system deals with this type of attack in general, rather than anything going wrong in the VPN connection itself,” says OpenVPN Access Server Product Manager, Johan Draaisma. --- snap --- The original report on oss-sec also says that this attack is not about any particular VPN implementation, but about VPNs are being handled in the kernel, so I am not sure whether this bug report is correctly titled and issigned at this point.
Research is currently ongoing if the Linux Kernel XFRM is affected, but so far it is considered not affected.
LibreSwan statement: https://libreswan.org/wiki/FAQ#Libreswan_is_not_vulnerable_to_CVE-2019-14899_.22Inferring_and_hijacking_VPN-tunneled_TCP_connections.22 Libreswan is not vulnerable to CVE-2019-14899 "Inferring and hijacking VPN-tunneled TCP connections" Vulnerability disclosure: https://seclists.org/oss-sec/2019/q4/122 The Linux IPsec implementation (XFRM) is a "policy based VPN" and does not accept unencrypted packets for IP ranges for which it has an IPsec encryption policy, irrespective of the rp_filter setting. When using VTI or XFRMi to create a "routing based VPN", AND disabling rp_filter protection for spoofed traffic, libreswan is still not vulnerable as it places the obtained VPN client IP address on the loopback device with a non-global scope of 50, resulting in the unencrypted packet still being dropped. An additional defense can still be deployed in libreswan using the tfc=1000 (or tfc=1500) option which causes all outgoing ESP traffic to be padded to 1000 bytes (or the path MTU when specifying more than what would otherwise fit) ensuring that nothing can be learned from the size of the encrypted ESP packet.
All done, closing.