this post was submitted on 09 May 2024
69 points (98.6% liked)

Linux

48157 readers
888 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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.

top 18 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 6 months ago* (last edited 6 months ago) (1 children)

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.

[–] [email protected] 1 points 6 months ago* (last edited 6 months ago)

Actually my firewall is persistent, just like many of the other good VPN clients, so "kill switch" is a bit of a misnomer. Which is why I called it wg-lockdown, named after Mullvad's lockdown mode. Persistent firewalls are effective, they just add a very tiny side-channel, as discussed in the link in my post. I just used the terms "kill switch" in my post because that's what many other people use.

Though the point about the LAN is a good point, I didn't consider that. I added LAN access because without it, the firewall was interfering with the networking of my docker container and virtual machines, which use local subnets. Even the official Mullvad client has issues with this. What do you recommend in this case? Manually whitelist the local subnets used by docker and my other virtual networks?

Edit: actually upon reading Mullvad's statement on TunnelVision, I realized that my firewall is still effective because it only allows traffic directed to LAN IP's to bypass the VPN. So regular internet traffic will be blocked if the attacker tries to redirect it to the LAN. I'm glad I used Mullvad as a reference implementation 😅

[–] [email protected] 2 points 6 months ago* (last edited 6 months ago) (2 children)

~~The vulnerability doesn't work on Linux~~

[–] [email protected] 13 points 6 months ago (1 children)

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...

[–] [email protected] 1 points 6 months ago (1 children)

Oh. It doesn't work with WireGuard then. It probably works with garbage. Thank you.

[–] [email protected] 10 points 6 months ago (1 children)

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.

[–] [email protected] 2 points 6 months ago* (last edited 6 months ago) (1 children)

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.

[–] [email protected] 1 points 6 months ago (2 children)

I thought TunnelVision applies to all VPN users that don't use firewall / network namespaces

[–] [email protected] 1 points 6 months ago* (last edited 6 months ago)

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.

[–] [email protected] 1 points 6 months ago (1 children)

It doesn't apply to Linux unless you do split tunnel, which no commercial VPN configs use, because it doesn't make sense to

[–] [email protected] 1 points 6 months ago

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.