We found that our Windows app’s firewall rules did not properly block DNS outside the VPN tunnel when split tunneling was used. However, programs would not really use this hole or cause any leaks.
When the Mullvad app is connected, DNS is supposed to only ever go inside the VPN tunnel, to the resolver on the VPN server. All other destinations should be blocked, both inside and outside the tunnel. The exception is of course if Custom DNS is being used, then the configured custom resolver is the only one that should be allowed. However, there was an issue with the firewall rules in our split tunneling driver that caused these security guarantees to not be fully upheld. If you excluded any app from the VPN tunnel, the split tunneling driver was activated and you could then also reach any DNS server outside the tunnel.
We don’t classify this as a critical vulnerability. We configure our in-tunnel DNS resolver as the system’s default resolver, and as such, Windows always uses the correct resolver anyway. The only time this would actually cause a leak is if a program explicitly tries to reach some other resolver outside the tunnel. Wrong DNS servers in the tunnel was still being correctly blocked.
The only affected app version is 2022.1 (and the betas preceding it). The bug was fixed in 2022.2-beta1. If you care about this leak, consider upgrading to the beta. This will be in a stable version of the app soon. This leak only affects Windows.
How to reproduce
If you have a DNS resolver on your local network, for example in your router, on IP
192.168.1.1, and you have our app connected and with no apps excluded from the tunnel, then the following command does not work. It times out without being able to reach the DNS server:
nslookup mullvad.net 192.168.1.1
But, if you exclude any program from the tunnel in the split tunneling settings and re-run the above command, you will see that it is now able to do the lookup.