TunnelVision vulnerability has existed since 2002 and may already be known to attackers.

Pulling this off requires high privileges in the network, so if this is done by intruder you’re probably having a Really Bad Day anyway, but might be good to know if you’re connecting to untrusted networks (public wifi etc). For now, if you need to be sure, either tether to Android - since the Android stack doesn’t implement DHCP option 121 or run VPN in VM that isn’t bridged.

  •  Slotos   ( @Slotos@feddit.nl ) 
    37•13 days ago

    Control of the DHCP server in the victim’s network is required for the attack to work.

    This is not a VPN vulnerability, but a lower level networking setup manipulation that negates naive VPN setups by instructing your OS to send traffic outside of VPN tunnel.

    In conclusion, if your VPN setup doesn’t include routing guards or an indirection layer, ISP controlled routers and public WiFis will make you drop out of the tunnel now that there’s a simple video instruction out there.

      •  NeuronautML   ( @NeuronautML@lemmy.ml ) 
        6•11 days ago

        Mullvad has written a post about it Here.

        FYI

        The desktop versions (Windows, macOS and Linux) of Mullvad’s VPN app have firewall rules in place to block any traffic to public IPs outside the VPN tunnel. These effectively prevent both LocalNet and TunnelVision from allowing the attacker to get hold of plaintext traffic from the victim.

        Android is not vulnerable to TunnelVision simply because it does not implement DHCP option 121, as explained in the original article about TunnelVision.

        iOS is unfortunately vulnerable to TunnelVision, for the same reason it is vulnerable to LocalNet, as we outlined in our blog post about TunnelCrack. The fix for TunnelVision is probably the same as for LocalNet, but we have not yet been able to integrate and ship that to production.

        I gotta say, i am really impressed with Mullvad. They’re not just a VPN seller. They write security compromise bulletins regularly and as soon as vulnerabilities show up and they actively lobby at the EU organs for more privacy laws. They really work and live their identity in every way.

  •  narc0tic_bird   ( @narc0tic_bird@lemm.ee ) 
    30•13 days ago

    The title is misleading in that the attack isn’t against the VPN apps or even the VPN protocols, but against the networking stack of the operating system.

    I also don’t get much value out of the statement that “every” OS except Android is vulnerable. Do they really mean all other OSes, or just what would come to mind for most people, i.e. Windows, macOS, Linux, iOS? What about the various BSDs for example?

    •  0xtero   ( @0xtero@beehaw.org ) OP
      13•13 days ago

      I also don’t get much value out of the statement that “every” OS except Android is vulnerable. Do they really mean all other OSes, or just what would come to mind for most people, i.e. Windows, macOS, Linux, iOS? What about the various BSDs for example?

      It’s a DHCP manipulation attack, so every RFC 3442 compliant DHCP implementation implementing option 121 would be “vulnerable” (it’s not vulnerability though). Android apparently doesn’t implement it, so it’s technically impossible to pull off against Android device. There might be others, but I’d guess most serious server/desktop OS’es implement it.

      The title isn’t misleading at all, even though the “neutering their entire purpose” is a bit of a click-bait. This doesn’t affect ingress VPN at all.

      It’s an attack that uses DHCP features (according to RFC).

      It’s a clever way to uncloak egress VPN users, therefore it does have privacy impact since most of us use VPN for purposes of hiding out traffic from the local network and provider and there’s no “easy” fix since it’s just a clever use of existing RFC.