In light of the recent TunnelVision vulnerability I wanted to share a simple firewall that I wrote for wireguard VPNs.
https://codeberg.org/xabadak/wg-lockdown
If you use a fancy official VPN client from Mullvad, PIA, etc, you won’t need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad). This is if you use a barebones wireguard VPN like me, or if your VPN client has a poorly-designed kill switch (like NordVPN, more info here).
A firewall should mitigate the vulnerability, though it does create a side-channel that can be exploited in extremely unlikely circumstances, so a better solution would be to use network namespaces (more info here). Unfortunately I’m a noob and I couldn’t find any scripts or tools to do it that way.
You must log in or register to comment.
If you use a fancy official VPN client from Mullvad, PIA, etc, you won’t need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad).
According to the researchers…
The result of this is the user transmits packets that are never encrypted by a VPN, and an attacker can snoop their traffic. We are using the term decloaking to refer to this effect. 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.
Killswitches are insufficient protection since the TunnelVision attack never disables the VPN tunnel. The TunnelVision attackers are instructing your physical layer connection to route everything through a node of their choosing rather than killing your VPN connection, and since the VPN connection never drops, a killswitch will never engage. The VPN stays up, thinking it is doing a good job, but in the meantime your network interface has been instructed to route no traffic through the VPN and instead route everything to the location of the attacker’s choosing. I have heard that a couple of VPNs think their clients are not vulnerable here, but I haven’t seen independent conclusive proof one way or the other yet.
I suspect that your “Solution” also fails to mitigate the issues in TunnelVision because it allows LAN access to the physical interface. In a TunnelVision attack the hostile has to be on your LAN (or rather the same LAN you are on since I suspect that “The coffee shop wi-fi” is the more likely network for an attack like this) already, so if they’re going to tell your interface to route traffic somewhere else, in all likelihood that somewhere else will already be in the same LAN you are and their exfiltration will be allowed under your configuration.
The vulnerability doesn’t work on Linux
Unfortunately Linux is affected https://github.com/leviathansecurity/TunnelVision
TunnelVision appears to work on any operating system that has a DHCP client that implements support for DHCP option 121. Most modern operating systems support this such as Linux, Windows, iOS and MacOS. Notably, Android does not appear to have support for option 121 and remains unaffected.
A fix is available on Linux when configuring the VPN users host to utilize network namespaces.
I read the Arstechnica article too where they say Linux isn’t affected then link to the researchers video where they show Linux being affected…
Oh. It doesn’t work with WireGuard then. It probably works with garbage. Thank you.
I am afraid you are still a bit misled; WireGuard is exactly what they use for the demo video. In general the underlying protocol does not matter, since the vulnerability is about telling the system to direct the packages to the attacker, completely bypassing the VPN.
That “vulnerability” seems more like a case of “people who use hostile networks have not considered which features that work as designed should be disabled in their use case”.
Using untrusted networks is quite common, like coffee shop wifi or airport wifi.
Does it matter?
This is a vulnerability anyway and we should be take care of.
It does matter if people now advocate to routinely disable useful features by default because they are a problem for their particular use case.
what features are you talking about?
You’re still right in 99% of all use cases.
Nobody operates VPNs for privacy in split tunnel. So everyone running Linux that would be concerned about this is unaffected.
I thought TunnelVision applies to all VPN users that don’t use firewall / network namespaces
It doesn’t apply to Linux unless you do split tunnel, which no commercial VPN configs use, because it doesn’t make sense to
