• Railing5132@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    6 months ago

    Hate to rain on the Linux parade here, but didn’t the article say: “There are no ways to prevent such attacks except when the user’s VPN runs on Android.” and that Linux was just as vulnerable as Windows?

      • Railing5132@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        6 months ago

        I was going from this: (emphasis mine)

        Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.

    • 0xD@infosec.pub
      link
      fedilink
      English
      arrow-up
      0
      ·
      6 months ago

      It’s not as vulnerable but it still is.

      Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.

      • Macros@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        0
        ·
        6 months ago

        But in the details this attack is not that bad. E.g. NordVPN and I guess also other VPNs use firewall rules to drop traffic on normal network interfaces.

        Their side channel is still routing traffic away from the VPN channel. Then they can observe that there is no traffic and guess that the user either didn’t make requests in that moment or that he wanted to visit a website in the range covered by the route. They can not spy on the traffic.

        Also you can not quickly move into a network and apply this attack, as DHCP leases usually last 1 day or at least 1 hour. Only when they expire you can apply the attack (or you force the user to drop from the network, which is easy if they are using WPA2, but only possible by blocking the wifi signal if they are using WPA3)

        It is a serious issue and should be mitigated, but not as huge as news articles make it.

        • xabadak@lemmings.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          6 months ago

          I saw that but unfortunately it doesn’t detail how to set it up persistently on every boot. And I also haven’t seen anybody using this method, probably because of the lack of tooling around it. For example afaik the official Mullvad client on linux just uses a firewall.