this post was submitted on 09 May 2024
69 points (98.6% liked)
Linux
48143 readers
524 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
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
According to the researchers...
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.
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 😅