Systemd Opened Security Hole In Linux, VPNs Could Be Compromised

From LinuxReviews
Jump to navigationJump to search
Animals-ladybug.png

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). published 2019-12-07last edited 2019-12-08

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

Keep calm and gangnam style.jpg
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."

Inferring and hijacking VPN-tunneled TCP connections.
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."

Inferring and hijacking VPN-tunneled TCP connections.
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."

Inferring and hijacking VPN-tunneled TCP connections.
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".


avatar

Anonymous user #1

one month ago
Score 0++
The default is not rp_filter = 1 it is rp_filter = 0, but some distributions had set inconsistently to other defaults.
avatar

Anonymous user #2

one month ago
Score 0 You
interesting stuff
avatar

Anonymous user #3

one month ago
Score 0++

I think you've misunderstood some details of the report. The authors aren't telling anyone to use tcpdump on the victim device as part of the attack, they are just giving steps for the devs to replicate the behavior easily. That's not part of the attack.

I think that's a little too dismissive of the "academic" part. If the network you are connected to can find out you are looking at a website, that's no small issue. What if you live in a place where just visiting a website is criminal? I'm thinking this is dangerous for activists who use VPNs to visit websites their government does not want them to visit.
avatar

WaiLin

one month ago
Score 0++
There is a rather big difference between a) being able to confirm that you are vising cnn.com while you are downloading the front page of cnn.com if the attackers suspects that you are visiting cnn.com and b) being able to see what sites you are visiting without having to try the IPs of sites you could be visiting one by one. There's no practical way of carrying out any real-world attack.
Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.