CVE-2019-14899 Vulnerability Lets Attackers Sniff or Hijack VPN on *nix based

LTS_Tom · December 6, 2019, 6:44pm

[CVE-2019-14899] Inferring and hijacking VPN-tunneled TCP connections.

sysctl.d: switch net.ipv4.conf.all.rp_filter from 1 to 2

github.com/systemd/systemd

sysctl.d: switch net.ipv4.conf.all.rp_filter from 1 to 2

committed 03:29PM - 28 Nov 18 UTC

lkundrak

+10 -1

This switches the RFC3704 Reverse Path filtering from Strict mode to Loose mode.… The Strict mode breaks some pretty common and reasonable use cases, such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi). The strict filter also makes it impossible for NetworkManager to do connectivity check on a newly arriving default route (it starts with a higher metric and is bumped lower if there's connectivity). Kernel's default is 0 (no filter), but a Loose filter is good enough. The few use cases where a Strict mode could make sense can easily override this. The distributions that don't care about the client use cases and prefer a strict filter could just ship a custom configuration in /usr/lib/sysctl.d/ to override this.

github.com

systemd/systemd/blob/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e/NEWS#L73-L80


      
          * The "net.ipv4.conf.all.rp_filter" sysctl will now be set to 2 by
            default. This effectively switches the RFC3704 Reverse Path filtering
            from Strict mode to Loose mode. This is more appropriate for hosts
            that have multiple links with routes to the same networks (e.g.
            a client with a Wi-Fi and Ethernet both connected to the internet).
          
            Consult the kernel documetnation for details on this sysctl:
            https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

gzornetzer · December 6, 2019, 7:42pm

@LTS_Tom - thanks so much for posting this - very helpful analysis since I was having trouble digesting the news.
Although FreeBSD was mentioned in the disclosure, I hope that a default install of pfsense would be hardened against this problem, for those ppl using vpn client on their pfsense box.

LTS_Tom · December 6, 2019, 9:40pm

Just a reminder, and as I said in the video, this is a client side issue, not server. I am also less than clear if this would work when pfsnse is a client with a public WAN. As far as I know pfsense does not accept the packets and I am doubting it would use the rp_filter - loose option to allow packets to come in that way.

kevdog · December 6, 2019, 9:47pm

@LTS_Tom

Thanks for explanation. I’m no security researcher however this attack seems very difficult to pull off in the wild. Thanks for your explanation.

g-aitc · December 6, 2019, 11:13pm

Question does this apply only to systems running systemd as opposed to the classic init system?

LTS_Tom · December 6, 2019, 11:20pm

Short answer is no. The change was made on November 28 2018 in the systemd github, but it is also the defualt setting on some other systems not running systemd. So it really depends on each distro if they changed the rp_filter setting.

g-aitc · December 7, 2019, 2:38pm

Thanks Tom, need to do a little checking.

LTS_Tom · December 8, 2019, 3:48pm

You can test if you system is using rp_filter = 2 by typing
sudo sysctl --all | grep "\.\rp_filter"

Ubuntu 19.10 and by extension Pop_OS 19.10 have it set for each adapter

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.enp0s31f6.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.wlp5s0.rp_filter = 2