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.

  • AnEilifintChorcra@sopuli.xyz
    link
    fedilink
    arrow-up
    13
    ·
    8 months ago

    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…

    • Kairos@lemmy.today
      link
      fedilink
      arrow-up
      3
      arrow-down
      2
      ·
      8 months ago

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

      • metiulekm@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        10
        ·
        8 months ago

        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.

        • taladar@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          arrow-down
          11
          ·
          8 months ago

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

          • BaalInvokerA
            link
            fedilink
            arrow-up
            8
            ·
            8 months ago

            Does it matter?

            This is a vulnerability anyway and we should be take care of.

            • taladar@sh.itjust.works
              link
              fedilink
              arrow-up
              1
              arrow-down
              3
              ·
              8 months ago

              It does matter if people now advocate to routinely disable useful features by default because they are a problem for their particular use case.

                • taladar@sh.itjust.works
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 months ago

                  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.

                  • xabadak@lemmings.worldOP
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    7 months ago

                    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.