If i get this right, that attack only works before the tunnel is initiated (i.e. traffic encrypted), if the hosts is compromised, right? No danger from untrusted points inbetween, right?
This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.
Sounds to me like it totally works even after the tunnel has started.
More like a corrupt traffic cop. There are reasons you might want this kind of functionality, which is why it exists. Normally you can trust the cop (DHCP server) but in this case the cop has decided to send everyone from all streets down to the docks.
That being said, it apparently does not affect Mullvad apps on any platform other than iOS (Apple does not allow fixing it on iOS). I suspect other serious VPNs are also not vulnerable outside iOS, since it is prevented by simple leak prevention mechanism.