10 ms·

I looked at this in detail. This exploit is a nothing-burger for most decent VPNs. A simple "leak protection" (aka Killswitch) firewall rule completely negates

I looked at this in detail. This exploit is a nothing-burger for most decent VPNs. A simple "leak protection" (aka Killswitch) firewall rule completely negates this attack. All decent VPNs implement such a rule by default. Dealing with undesirable routes (whether pre existing or pushed by a DHCP server) is nothing new or in the slightest bit hard to defend against. If a VPN does not implement such a firewall rule already then it's likely already leaking so all this exploit demonstrates is that "A VPN without leak protection, leaks". (I won't even mention the "side channel" attack as it's completely ridiculous) I liked your write-up and option 121 is a little known option, so it's good to know about. But let's not pretend this thing is bigger than it is.

barbariangrunge 2y ago
Looking at mozilla vpn, I can’t tell if there is such a setting, unless it’s just enabled by default. Can anyone clarify?
- SushiHippie 2y ago
  > A VPN kill switch is a must-have for privacy reasons when using a VPN. If you are actively using the VPN to transfer data and your Internet connection becomes unstable or drops, the entire network connection on your device will be blocked to prevent your local IP address from being exposed to the outside world. The kill switch is on by default on Windows, Android, iOS, macOS and Linux and there is no setting to turn it off. https://support.mozilla.org/en-US/kb/mozilla-vpn-kill-switch https://support.mozilla.org/en-US/kb/mozilla-vpn-kill-switch
CommitSyn 2y ago
FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.
- banister 2y ago
  They don't know what they're talking about. Kill switches are not "tripped" there is no "control channel". A kill switch is just a firewall rule that is ALWAYS engaged and all it does is blocks off-VPN traffic. It 100% will defend against this exploit.
  - jcrawfordor 2y ago
    Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services offered by the OS. On some popular OS like mobile ones it's just not possible at all. So just to grab an example, NordVPN's implementation does indeed work as the article presents: it monitors the VPN and disables network access for applications if the VPN connection drops. This is indeed vulnerable to any number of potential problems, and depending on the OS and user savvy you can set up better protection using e.g. the iptables owner module. It's very non-portable though, sometimes even between Linux distributions, and hard to support at scale. Actually I'd say a true "no access except through the VPN" rule is easiest to implement on Windows, but NordVPN doesn't seem to do it there either, I'm not sure why. To be fair, it's right in the name: a kill switch is a switch that kills things. It isn't proper network policy like per-process routing tables that are, unfortunately, difficult to implement for consumer machines.
    - 0x457 2y ago
      Let's be honest, there're 2 OSs on desktop that matter to VPN providers that provide "all-in-one app" - Windows and macOS. Both have easy to configure from your application. On linux, well, you have to choose: - use iptables style rules regardless of the backend or - use nftables style rules regardless of the backend. So it's 3 firewalls that you have to think about. On mobile, well, on mobile you're mostly at the mercy of the platform owner and generally can't do much. Hence, why connecting phone to "SoftAP/ether_g + VPN" device is better than a direct connection.
    - banister 2y ago
      Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :) On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord really works like this i have an even lower opinion of them than i do currently). On linux - iptables (for example) - just implement a general DROP policy then override with a specific ALLOW on the tunnel interface. On Windows - Use WFP to implement a block everything rule, then provide a higher priority rule to allow on the tunnel interface. All three of these techniques are the recommended way to implement a kill switch and it's used heavily in the VPN industry by anyone sensible. It completely defends against this TunnelVision exploit too. The way that you suggest kill switch is implemented (reactive and monitoring the connection?) is very fragile, racey and prone to leak, i absolutely would not trust it and it shouldn't even be called a kill switch. It's an embarrassment. :)

barbariangrunge 2y ago

Looking at mozilla vpn, I can’t tell if there is such a setting, unless it’s just enabled by default. Can anyone clarify?

SushiHippie 2y ago
> A VPN kill switch is a must-have for privacy reasons when using a VPN. If you are actively using the VPN to transfer data and your Internet connection becomes unstable or drops, the entire network connection on your device will be blocked to prevent your local IP address from being exposed to the outside world. The kill switch is on by default on Windows, Android, iOS, macOS and Linux and there is no setting to turn it off. https://support.mozilla.org/en-US/kb/mozilla-vpn-kill-switch https://support.mozilla.org/en-US/kb/mozilla-vpn-kill-switch

CommitSyn 2y ago

FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

banister 2y ago
They don't know what they're talking about. Kill switches are not "tripped" there is no "control channel". A kill switch is just a firewall rule that is ALWAYS engaged and all it does is blocks off-VPN traffic. It 100% will defend against this exploit.
- jcrawfordor 2y ago
  Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services offered by the OS. On some popular OS like mobile ones it's just not possible at all. So just to grab an example, NordVPN's implementation does indeed work as the article presents: it monitors the VPN and disables network access for applications if the VPN connection drops. This is indeed vulnerable to any number of potential problems, and depending on the OS and user savvy you can set up better protection using e.g. the iptables owner module. It's very non-portable though, sometimes even between Linux distributions, and hard to support at scale. Actually I'd say a true "no access except through the VPN" rule is easiest to implement on Windows, but NordVPN doesn't seem to do it there either, I'm not sure why. To be fair, it's right in the name: a kill switch is a switch that kills things. It isn't proper network policy like per-process routing tables that are, unfortunately, difficult to implement for consumer machines.
  - 0x457 2y ago
    Let's be honest, there're 2 OSs on desktop that matter to VPN providers that provide "all-in-one app" - Windows and macOS. Both have easy to configure from your application. On linux, well, you have to choose: - use iptables style rules regardless of the backend or - use nftables style rules regardless of the backend. So it's 3 firewalls that you have to think about. On mobile, well, on mobile you're mostly at the mercy of the platform owner and generally can't do much. Hence, why connecting phone to "SoftAP/ether_g + VPN" device is better than a direct connection.
  - banister 2y ago
    Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :) On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord really works like this i have an even lower opinion of them than i do currently). On linux - iptables (for example) - just implement a general DROP policy then override with a specific ALLOW on the tunnel interface. On Windows - Use WFP to implement a block everything rule, then provide a higher priority rule to allow on the tunnel interface. All three of these techniques are the recommended way to implement a kill switch and it's used heavily in the VPN industry by anyone sensible. It completely defends against this TunnelVision exploit too. The way that you suggest kill switch is implemented (reactive and monitoring the connection?) is very fragile, racey and prone to leak, i absolutely would not trust it and it shouldn't even be called a kill switch. It's an embarrassment. :)