Systemd Opened Security Hole In Linux, VPNs Could Be Compromised
Attackers on the local network could discover that someone on the same network is using a VPN and they could, potentially, find out what sites are visited and even inject packets into a VPN users datastreams. This is all thanks to a change in systemd late 2018 which has now been adopted by all the major GNU/Linux distributions.
written by 윤채경 (Yoon Chae-kyung) 2019-12-07 - last edited 2019-12-08. © CC BY
The systemd developers Lubomir Rintel and Lennart Poettering decided to change Linux's default reverse path filtering on distributions using systemd from Strict mode (1) to Loose (2) with a systemd commit on November 28th, 2018. All the major GNU/Linux distributions who use systemd have adopted this change. The difference as described in Linux's ip-sysctl documentation is:
- 1 - Strict mode as defined in RFC3704: Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded.
- 2 - Loose mode as defined in RFC3704: Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail.
The kernel documentation notes that "Current recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDos attacks. If using asymmetric routing or other complicated routing, then loose mode is recommended.". The kernel itself defaults to a rp_filter setting of 0 (No source validation).
Security researches William J. Tolley, Beau Kujath and Jedidiah R. Crandall from the University of New Mexico discovered that the systemd change could be used to discover if a user on the local network is using a route based VPN or not. They published their findings as CVE-2019-14899 with details in a message to the Open Source Security Mailing List titled CVE-2019-14899: Inferring and hijacking VPN-tunneled TCP connections..
Their attack, which is rather theoretical beyond it's first step, works on the latest versions of the major GNU/Linux distributions (Ubuntu, Fedora and Debian). Common VPN software such as OpenVPN and WireGuard is affected. An attacker on the local network could, in theory, find out if someone is using a VPN, find out what virtual IP their VPN has, check if the target is accessing a specific IP and it is, in theory, even possible to inject data into a VPNs TCP streams.
Tor and policy-based VPN clients are not affected.
It Is Not As Bad As It Sounds[edit]
There is no need to panic if you are using a VPN. You can keep calm and Gangnam Style.
The potential attack on VPN users running a GNU/Linux distribution would have to be done from the local network. It is done by
"sending SYN-ACK packets to the victim device across the entire virtual IP space (the default for OpenVPN is 10.8.0.0/24). When a SYN-ACK is sent to the correct virtual IP on the victim device, the device responds with a RST; when the SYN-ACK is sent to the incorrect virtual IP, nothing is received by the attacker."
on the oss-sec mailing list November 4th, 2019
This works; it is possible to see that someone else on the network has a private IP commonly used for VPN traffic if Linux's rp_filter is set to 2 - which is now the systemd default. This can easily be changed by creating a file called /etc/sysctl.d/51-rpfilter.conf with the contents net.ipv4.conf.all.rp_filter=1
The next step in an attack becomes far more academic:
"Similarly, to test if there is an active connection for any given website, such as 64.106.46.56, for example, we send SYN or SYN-ACKs from 64.106.46.56 on port 80 (or 443) to the virtual IP of the victim across the entire ephemeral port space of the victim."
on the oss-sec mailing list November 4th, 2019
If you know someone's using a website because you have a camera pointed at their laptop (after all, this is an attack which requires you to be on the same local network) then it's easy to check if there is an active connection to that website using this attack. You would, of course, already know that they are using some website if you have a camera pointed at the victims screen. Blindly guessing IPs they could be connecting to is a different matter, the IP space is fairly large and you would have to test for possible IPs while a TCP connection is active.
The security disclosure goes on to in-detail describe a way to arbitrarily inject data into the active TCP connection. While theoretically possible it's a practical non-issue. First of all, you would have to know what website or other IP the victim is connecting to. Secondly, it has to be done while the connection is open. That's not a very huge window. Lastly, there is one minor problem practical problem with the approach laid out in the attack's description:
"You can run tcpdump on the victim machine to accelerate the testing of his process by viewing the actual sequence and acknowledgement numbers."
on the oss-sec mailing list November 4th, 2019
Well... No. You probably can't run tcpdump on some random victim's computer. And you would already have root access to it if you can - in which case you don't need to do some theoretical attack.
Tor differes from VPN services. It uses SOCKS for it's connections. It is therefore not affected.
GNU/Linux users who worry about this mostly theoretical attack can protect themselves by setting the reverse path filter to strict by creating /etc/sysctl.d/51-rpfilter.conf with net.ipv4.conf.all.rp_filter=1:
echo "net.ipv4.conf.all.rp_filter=1" >/etc/sysctl.d/51-rpfilter.conf
The new setting can be applied run-time with sysctl --system
Attacks like this one are interesting from a technical point of view and they can sound scary and dramatic. They become far less dramatic once you look at the possible practical real-world scenarios. The odds of this affecting anyone actually using a VPN in the real world are very slim. You can keep calm and Gangnam Style even if you are using affected VPN software with the fp_filter set to "loose".
Enable comment auto-refresher
WaiLin