sharing my simple wireguard kill-switch for Linux
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.
The vulnerability doesn't work on LinuxUnfortunately Linux is affected https://github.com/leviathansecurity/TunnelVision
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".
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?
The ability to set static routes via DHCP server or for that matter the ability to remote boot systems via DHCP server which has similar problems if you can't trust the DHCP server.
I see what you mean now. I wouldn't advocate for people to disable DHCP features either. It should be the VPN provider's responsibility to provide a proper VPN client that mitigates attacks like these.
Using untrusted networks is quite common, like coffee shop wifi or airport wifi.
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
A separate routing table that takes precedence over the one modified by DHCP should works as well I think. Oh, and of course you have to use a vpn that forces its own nameserver or set one manually to prevent redirections.
It doesn't apply to Linux unless you do split tunnel, which no commercial VPN configs use, because it doesn't make sense to
why is a split tunnel relevant? I thought all VPNs are vulnerable unless they use a firewall like I do, or network namespaces.
At least the way I understand it, a normal VPN redirects your internet traffic to instead go through a virtual network interface, which then encrypts and sends your traffic through the VPN. This attack uses a malicious DHCP server to inject routes into your system, redirecting traffic to the attacker instead of towards the virtual network interface.