TunnelVision - CVE-2024-3661 - Decloaking Full and Split Tunnel VPNs - Leviathan Security Group.
Ars Technica published a story on this:
This attack is not a VPN App flaw or anything the VPN provider would be responsible for.
It is in fact an OS specification for DHCP being misused, a functionality called Option 121 which should normally be implemented - and usually is, except for Android (AOSP didn’t see any use for it so did not implement it; and this is why they are the only DHCP implementation immune to this attack)
Quoting the article, here is a brief description;
The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network. A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel. By using option 121 to route VPN traffic through the DHCP server, the attack diverts the data to the DHCP server itself
From what I understand, this is less of a concern when using your own LAN at home, because in order to activate this option 121 functionality, one either needs administrative control of the network in order to configure the DHCP server to use option 121, or there needs to be a rogue DHCP server inside your LAN configured. In both cases, you already have a bigger problem than your VPN connection leaking outside the encrypted tunnel…
But when using a VPN over untrusted public wifi networks, you don’t know how the DHCP server is configured and you wouldn’t be able to tell if unencrypted traffic is being diverted from the TUN; furthermore, no killswitch will be triggered and the VPN will report that everything is GO while your internet traffic is being snooped on!
This DHCP option is defined in RFC 3442 (dated 2002), which notes that similar vulnerabilities exist in earlier DHCP options defined in RFC 2132 (dated 1997).
Thank you for your link to Qubes Forum which discusses this attack. I am relieved to read there, that they confirm QubesOs would generally be immune to this attack - unless your VNP tunnel is being established inside the real world internet facing qube. Most people put their VPN qube behind sys-firewall, which is itself behind sys-net or sys-usb.
But still, what is the situation with all Purism’s products running on Linux? Looks like there is no way to thwart this attack at present. I have read one third of the 254 comments on Ars Technica about the article: there are some really interesting suggestions and ideas, but this looks like a complicated problem that should be solved globally at the OS level.
I feel that this attack is pretty bad news, since this is exactly the situation where we would absolutely need to use a VPN, over untrusted/insecure networks like public wifi hotspots at airports, hotels, cafés, etc…
I wasn’t talking about my home LAN, for which it is my own responsability to assess the security.
I am concerned about using wifi hotspots on untrusted networks when not at home, for which you necessarily have to connect to through their DHCP server - and you have no way of knowing if Option 121 was configured…
So I will rephrase your comment this way: Seems pretty simple…don’t connect to the internet outside your home.
Unfortunately
I take issue with “neuters their entire purpose”: only if you fall for the YouTube marketing about the P in VPN being “privacy” rather than “private network”.
I use a VPN for work. This attack would render my connection to work services unusable, therefore it would be pretty noticeable. Same for my Tailscale VPN for accessing my home network when away.
Fair point. I almost always rely on my cellular connection for data when I am out, but sometimes there’s only wifi. We need a Tunnelvision detector… or at least an Option 121 detector.
Reflecting a bit more on this, it needs to be looked at in a more positive manner: Seems pretty simple…only use QubesOs for connecting to a VPN while outside your home LAN
At a high level, this attack applies regardless of the network technology, provided that DHCP is used to get an IP address. So a cellular connection does not guarantee safety against this attack.
A cellular connection might use PPP instead of DHCP. Even then you would have to study the PPP specs carefully to make sure that similarly problematic options don’t exist.
The only true fix that I can see is … all network connections that use DHCP by default ignore option 121 (and option 33). For a trusted network you have the choice to override that and respect those options. (At work, you might need those options. At home you most likely won’t. Anywhere else … don’t.)
