A while back we were notified by an external person about a potential privilege escalation attack towards the Windows version of our app. The attack works against 2020.3 and older versions of the app.
By the time this blog post is published, the majority of our users have already upgraded to 2020.4 and are thereby already protected. Furthermore, the threat is only relevant if you have a Windows user account named build and you do not want the people that are controlling said account from being able to become administrators on the machine. In summary: This is very likely not an issue for you!
At the time when we were notified of this vulnerability we were already working on an unrelated code change that would make the attack impossible. This together with the fact that exploiting the vulnerability require a very unusual setup, we classified it as unlikely and not critical. We continued with our unrelated code change and released version 2020.4 where the attack was no longer possible, and without announcing there was a known vulnerability.
In hindsight we realize it was clearly against our own transparency culture to not communicate this known vulnerability to our users, even if it was not likely to affect anyone. We are sorry about that and want to set the record straight now. And to be very clear, we do not think any of our users has come to harm or has had the setup needed for the attack to ever be possible or relevant.
The privilege escalation attack is based on our mullvad-daemon.exe system service running with SYSTEM privileges trying to load an OpenSSL config file from C:\Users\build\mullvadvpn-app\dist-assets\binaries\msvc-openssl\openssl.cnf. If this file existed it would load and use it. This file could then contain instructions that made the process load and execute a malicious DLL-file as the SYSTEM user. This could compromise the entire system.
The reason why we did not classify this as a critical vulnerability is that the attacker would need to be able to write to C:\Users\build\mullvadvpn-app\dist-assets\binaries\msvc-openssl\openssl.cnf to carry out the attack. The only realistic way this could happen is if the attacker were in control of a user account named build. Having a user with this name is of course fully possible, but we do not think it is very common. The most likely place where this would exist would be on some build server, and on such a server it is probably not very common to run a VPN client. Also, most people having access to a build server are likely already admin users, meaning a privilege escalation is pointless.
The unrelated change in the app that made the attack impossible in 2020.4 is that we got rid of OpenSSL completely and replaced it with rustls. As a result, the code loading the OpenSSL configuration file is no longer present in our VPN client.