Technology

Common Linux w

Android

Except sometimes.

Put another way, this means that a malicious coffee shop or hotel can eavesdrop on all VPN traffic on their network. That's a really big fucking deal.

This is the primary reason folks use VPNs - to protect themselves on public networks. I would say it's definitely not a non-issue.

Not quite, this could be exploited by telecom providers when using mobile data. Also using a VPN for networks you DON'T control is one of the more popular uses of the things

Maybe it affects BSD and MacOS.

It also can affect some Linux systems based on configuration. Android doesn't implement the exploited standard at all and is always immune.

The problem isn't them being in you LAN. It's about going to an untrusted network (eg Starbucks, hotel) and connecting to your VPN, boom, now your VPN connection is compromised.

The other comment already covers the fact that VPN should be useful exactly when you are connected to untrusted LANs. I want to add that also the main point of your comment is anyway imprecise. You don't need a compromise DHCP, you just need another machine who spoofs being a DHCP. Not all networks have proper measures in place for these attacks, especially when we are talking wireless (for example, block client-to-client traffic completely). In other words, there is quite a middle-ground between a compromised router (which does DHCP in most cases) and just having a malicious device connected to the network.

My understanding is that if you run a rogue discoverable DHCP server in a local network with a particular set of options set and hyper-specific routing rules, you can clobber the routing rules set by the VPN software on any non-Android device, and route all traffic from those devices through arbitrary midpoints that you control.

But IANANE (I am not a network engineer) so please correct my misinterpretations.

(obligatory I'm not a network surgeon this is likely not perfectly correct)

The article mentions network interfaces, DHCP and gateways so real quick: a network interface usually represents a physical connection to a network, like an Ethernet port or a WiFi card. DHCP is a protocol that auto configured network routes and addresses once a physical connection is established, like when you jack in via an ethernet cable, it tells you the IP address you should go by, the range of IP address on the network you've connected to, where you can resolve domain names to IP addresses. It also tells you the address of a default gateway to route traffic to, if you're trying to reach something outside of this network.

You can have more than one set of this configuration. Your wired network might tell you that your an address is 10.0.0.34, anything that starts with 10.0.0. is local, and to talk to 10.0.0.254 if you're trying to get to anything else. If at the same time you also connect to a wireless network, that might tell you that your address is 192.168.0.69, 192.168.0.* is your local network, and 192.168.0.254 is your gateway out. Now your computer wants to talk to 4.2.2.2. Should it use the wireless interface and go via 192.168.0.254? or the wired one and use 10.0.0.254? Your os has a routing table that includes both of those routes, and based on the precedence of the entries in it, it'll pick one.

VPN software usually works by creating a network interface on your computer, similar to an interface to a WiFi card, but virtual. It then asks the OS to route all network traffic, through the new interface it created. Except of course traffic from the VPN software, because that still needs to get out to the VPN provider (let's say, at 1.3.3.7) via real Internet.

So if you're following along at home, your routing table at this point might look like this:

• traffic to 1.3.3.7 should go to 10.0.0.254 via the wired interface
• all traffic should go to the VPN interface
• traffic to 10.0.0.* should go to the wired interface
• all traffic should go to 10.0.0.254 via the wired interface
• traffic to 192.168.0.* should go to the wireless interface
• all traffic should go to 192.168.0.254 via the wireless interface

whenever your os wants to send network packets, it'll go down this list of rules until one applies. With that VPN turned on, most of the time, only those two first rules will ever apply.

If I'm reading the article correctly, what this attack does, is run a DHCP server, that when handing out routing rules, will send one with a flag that causes, for example, the last two rules to be placed at the top of the list instead of the bottom. Your VPN will still be on, the configuration it's requested the OS to make would still be in place, and yet all your traffic will be routed out to this insecure wireless network that's somehow set itself as the priority route over anything else.

Efforts have been put in for several decades now

I still remember all the hype around "IPv6" day about 12 years ago...

Any day now...

No - the VPN provider has another DHCP server for use 'inside' the VPN.

This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.

Sounds to me like it totally works even after the tunnel has started.

No, it works at any point and the local network needs to be compromised (untrusted), the host can be secure.

So it is likely not an issue at your home unless you have weak Wi-Fi password. But on any public/untrusted Wi-Fi, it is an issue.