• drspod@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    Now that TunnelVision has been disclosed to the general public

    That vulnerability affected every OS except Android.

    • Telorand@reddthat.com
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      6 months ago

      Yes, but you can relegate your network interface to a namespace in Linux, which is a remedy the researchers recommend. You have to use your internet-facing programs in a VM in Windows to achieve the same effect, and that’s a lot of overhead just to protect yourself.

      Edit: typo

      • Buelldozer@lemmy.today
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        6 months ago

        You have to use your internet-facing programs in a VM in Windows to achieve the same effect

        Eh, there’s 20 different ways to detect DHCP Option 121 fuckery and once you know it’s happening its fairly trivial to stop. Any VPN client worth its salt will be updated in 60 days or less to fix this and existing VPN clients can be hardened against TunnelVision with some fairly simple scripting.

        It’s a serious vulnerability but it’s hardly the unfixable world ender that the media has made it out to be.

        • Telorand@reddthat.com
          link
          fedilink
          arrow-up
          0
          ·
          6 months ago

          Good to know. Got any specific sources for the scripting, or should I just search for something like “option 121 mitigation?”

          • Buelldozer@lemmy.today
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            6 months ago

            I don’t know if there’s any pre-built scripting out there (yet) for this but it’s relatively straight forward in Windows to use powershell and either look in the registry for the assigned dhcp options ( HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp\Parameters\Options) or check the routing table for illogical routes.

            Assuming that you aren’t using split tunneling you could also have powershell check your external IP address for the expected result.

            Another possibility is to grab the dhcp test tool from Github, run it in non-interactive mode and then parse it’s output. Something I find VERY interesting is that Andrey Baranov specifically added Option 121 to that tool in March of 2023!

            With any of those it’s a matter of what you want to have happen when you detect the problem such as warning the user and disconnecting the vpn or attempting to mitigate the problem by reconfiguring the routing table.

            I should point out that Option 121 is a legit thing and it does have valid uses so you can’t assume something nefarious just because it’s being used.

            I’ll probably be scripting up a remediation over the next few days, I’ll try and remember to come back and share what I did.