Mullvad app and servers unaffected by OpenSSL CVE-2020-1967

On the 14th of April, we were alerted that a vulnerability would be released today via https://mta.openssl.org/pipermail/openssl-announce/2020-April/000170.html.
Since the severity was reported as HIGH, we investigated which portions of our service would be vulnerable to this. We did the following:

• We put up a notification on our servers page https://mullvad.net/servers/#/ warning users of a short per-server downtime last week so that users could make preparations as needed. At the same time we planned to make OpenVPN upgrades with other improvements
• We made preparations for making a new release of the Mullvad VPN app with the fixed OpenSSL version if needed.
• We made preparations to be able to deploy our servers with an unaffected version as soon as it became available in the repositories of Debian and Ubuntu.

Today, the OpenSSL project released security advisory https://www.openssl.org/news/secadv/20200421.txt, CVE-2020-1967. It is clear that this vulnerability is limited to a Denial of Service attack by a malicious TLS client or server as a worst case scenario. Additionally, this vulnerability only affects OpenSSL versions 1.1.1d, 1.1.1e and 1.1.1f.

No impact on the app

The Mullvad VPN app uses OpenSSL in three places; in OpenVPN, Shadowsocks and when communicating with our API servers.

Both OpenVPN and Shadowsocks run as subprocesses to the daemon. The bug itself is a null pointer dereference which can only cause the process that triggers the bug to crash. This means that if the bug were to be triggered in OpenVPN or Shadowsocks, the subprocesses would crash/exit. The daemon would treat it as a normal connection interruption, clean up and establish a new tunnel, all while keeping the system security tight with the firewall.

The part of the daemon that communicates with our API servers does not call the function with the null pointer dereference bug (SSL_check_chain), so it can not trigger it.

Impact on our infrastructure

We only use affected versions of OpenSSL on a few servers for reporting system metrics for our internal infrastructure. All of our other servers, including OpenVPN and Wireguard VPN relays, as well as our API and website, are unaffected.

In summary, this vulnerability does not affect any of our public facing infrastructure, and for our internal infrastructure, access to the monitoring server is limited to our own internal servers.

We will be making the aforementioned upgrades to OpenVPN, along with upgrading the OpenSSL version we use for server metrics, as planned. We expect this work to be completed on or before Friday, April 24th, 2020.