Https://m.slashdot.org/story/364288

https://m.slashdot.org/story/364288

Have you all seen this?

Here are some suggested fixes;

Confusing writeup & title (+5, Informative)

bill_mcgonigle 3 days ago

The real story is buried under a pile of confusing crap.

Basically what's going on, for linux, is this:

You have a NIC, say eth0, with IP 1.1.1.1 . You connect to a VPN and get a tun0 with IP 2.2.2.2 .

Here is the problem: Somebody who can send packets to your NIC (wifi, unswitched ethernet, arp-poisoned switched Ethernet) can send a packet destined for 2.2.2.2 to your eth0 and it will RESPOND back out eth0 as if it had come in tun0.

net.ipv4.conf.default.rp_filter = 1

should turn that off for ipv4. They claim this setting works for now but may not under further attacks, though I don't see what they're planning to do. They also recommend iptables rules to drop appropriately. I've configured my bsd routers this way forever and performance is fine there.

At this point, they know your IP and can do what sounds like a massively luck-required attack to figure out what the remote host is that you are talking to over the network and from there your current sequence number and from there do packet injection. Remember, they're injecting on your eth0 for the address on tun0. They are penetrating some of the security the VPN should be providing but they are not hijacking your VPN - they are guessing about the traffic tunneled inside of it.

A VPN's variable packet size helps narrow the scope of the latter attack, so if you're concerned then you should see if your VPN software allows packet padding so all packets are at your MTU size. That's slower and more secure; ideally they would also all be constant-time as well.

Simple fix (+1)

dskoll 3 days ago

Suppose your VPN interface is vpn0 and your VPN IP address is 10.0.8.1. Then this should fix it:

iptables -I INPUT --destination 10.0.8.1 -i ! vpn0 -j DROP

Reply

Share

Flag

Re: Simple fix (+4, Interesting)

dskoll 3 days ago

Ugh, I should have read the man page.

iptables -I INPUT --destination 10.0.8.1 ! -i vpn0 -j DROP

Isn't this fixed in the kernel? Or am I misunderstanding things.

1 Like

It omits [1] that somebody would have to be an adversary (adjacent attacker) being in control of assigning IP addresses and routing to hosts that are to be attacked. Hence, not really a general issue in itself for an (uncompromised) router running OpenWrt and/or its various VPN implementations.

Nonetheless, the vulnerability could potentially be leveraged by an ISP a/o state actor on the WAN side and then only if dropping of invalid packets is not enabled.


[1] https://seclists.org/oss-sec/2019/q4/122


by default kernel nf responds to any unsolicited ingress traffic (on any iface) unless otherwise configured (ipt a/o nft a/o bpf), e.g. conntrack and dropping of invalid packets.

WireGuard userland (wg-quick) latest snapshot now implements ipt rules for mitigation purposes.

2 Likes

Enabling of "dropping of invalid packets" in firewall settings results in me not being able to communicate with any LAN devices via remote openvpn TAP connection. However, via openvpn TUN I can.

Is TAP incompatible "dropping of invalid packets" Don't suppose you would know a solution to this?

Update: I can ping devices over TAP with "dropping of invalid packets" enabled but cant connect in a meaningful way??