|
| 1 | +# 2025-03-20 Assured's audit of the installer downloader |
| 2 | + |
| 3 | +Between 2025-03-10 and 2025-03-17 [Assured Security Consultants] performed a review of |
| 4 | +the distributed app download solution being developed by Mullvad VPN AB. |
| 5 | + |
| 6 | +In scope for the audit was the installer downloader application, the script generating |
| 7 | +installer releases, and the installer metadata. |
| 8 | + |
| 9 | +Quoting the key conclusions and recommendations chapter of the report: |
| 10 | + |
| 11 | +> Based on our review of the source code, the new downloader installer solution seems to be |
| 12 | +> well thought out and implemented. |
| 13 | +> |
| 14 | +> Our observations has identified some minor issues and notes. |
| 15 | +> |
| 16 | +> Our recommendations can be summarized as follows: |
| 17 | +> |
| 18 | +> * Review the integrity check in the script `4-make-release` |
| 19 | +> * Consider if the TOCTOU is really mitigated by the randomly generated directory name |
| 20 | +> * Increase the number of characters in the randomly generated directory name |
| 21 | +
|
| 22 | +The [full audit report] can be found next to this file. |
| 23 | + |
| 24 | +[Assured Security Consultants]: https://www.assured.se/ |
| 25 | +[full audit report]: ./2025-03-20-assured-MUL020_Installer_Downloader_Audit.pdf |
| 26 | + |
| 27 | +## Overview of findings |
| 28 | + |
| 29 | +This chapter will list the four findings from the report along with Mullvad's response |
| 30 | +to them. |
| 31 | + |
| 32 | +### 3.1 Release script does not verify that the key that has signed the binary is trusted (LOW) |
| 33 | + |
| 34 | +The script we use to automate part of the desktop app release process (`4-make-release`) uses |
| 35 | +`gpg --verify` to ensure that the installers it has fetched from Mullvad's internal release |
| 36 | +servers are not tampered with. |
| 37 | +Both the installer and the accompanying signature comes from the same server. |
| 38 | + |
| 39 | +The audit report claims that `gpg --verify` will succeed as long as the signature matches the data, |
| 40 | +no matter which key produced the signature. This claim is not fully accurate according |
| 41 | +to our own tests. `gpg --verify` will exit with an exit code of zero if the signature |
| 42 | +matches the data _and the key that produced the signature is in the local GnuPG keyring_. |
| 43 | +Since we only import the Mullvad code signing key on the machines where we perform releases, |
| 44 | +we think our usage of `gpg --verify` is currently pretty safe with the configuration |
| 45 | +we are using. However, after discussing the matter in more detail with Assured we have together |
| 46 | +identified two potential risks here: |
| 47 | +1. GnuPG can be configured to automatically fetch keys from a keyserver when it verifies |
| 48 | + a signature it does not have the key for. This could render the check useless, but |
| 49 | + this behavior is currently disabled in the default configuration. |
| 50 | +2. GnuPG can be configured to automatically use any public key bundled with the |
| 51 | + detached signature that it is verifying. This could render the signature check useless, |
| 52 | + but this behavior is also disabled by default. |
| 53 | + |
| 54 | +The manpage for `gpg` explicitly states that only using the exit code, like we do, for signature |
| 55 | +validation is not appropriate. So Assured is correct in pointing out this behavior as risky. |
| 56 | +Both Assured and the manpage for `gpg` recommends `gpgv` as an alternative for usage in scripts. |
| 57 | +However, even `gpgv` is a bit unclear about how it handles key servers and bundled pubkeys. |
| 58 | +So instead we decided use [Sequoia] to verify the signatures, as it allows explicitly specifying |
| 59 | +what PGP pubkey to trust. It also does not require us to initialize any keyring, so it is simpler |
| 60 | +to use as well. |
| 61 | + |
| 62 | +[Sequoia]: https://sequoia-pgp.gitlab.io/sequoia-sq/man/sq-verify.1.html |
| 63 | + |
| 64 | + |
| 65 | +### 3.2 `deserialize_and_verify` function does not return the exact data that is signed and verified (NOTE) |
| 66 | + |
| 67 | +This finding is about how we verify and use the signed metadata containing information about |
| 68 | +available app versions. The design of this system is largely influenced by [The Update Framework]. |
| 69 | + |
| 70 | +The way the code worked at the time of the audit was roughly the following: |
| 71 | + |
| 72 | +1. Download signed metadata JSON and deserialize to `partial_data`. This object contains |
| 73 | + the signature (`partial_data.signatures`) and the signed data (`partial_data.signed`). |
| 74 | +2. Serialize `partial_data.signed` to Canonical JSON and call it `canon_data`. |
| 75 | +3. Verify the signature against `canon_data`. |
| 76 | +4. If the signature matched, return `partial_data.signed` and trust it. |
| 77 | + |
| 78 | +The audit points out that if the library that performs serialization to canonical JSON has a bug |
| 79 | +that translates `partial_data.signed` in the wrong way, we might pass verification, and then end |
| 80 | +up using malicious data that was lost in the serialization process. |
| 81 | +The recommendation here is to deserialize `canon_json` and return that as the trusted metadata. |
| 82 | + |
| 83 | +A sidenote here is that the code was initially implemented according to the recommendation. |
| 84 | +The code was changed to return `partial_data.signed` just before the audit. This change was |
| 85 | +a result of a pre-audit meeting between Mullvad and Assured where we probably missunderstood |
| 86 | +some of their early feedback on the metadata verification best practices. |
| 87 | + |
| 88 | +We [changed the implementation back] to only use the verified data, as recommended. |
| 89 | + |
| 90 | +[changed the implementation back]: https://github.com/mullvad/mullvadvpn-app/pull/7859/commits/1b6456794e1f784691f04a28540e4812eb6e7543 |
| 91 | +[The Update Framework]: https://theupdateframework.io/ |
| 92 | + |
| 93 | + |
| 94 | +### 3.3 Short random directory name (NOTE) |
| 95 | + |
| 96 | +The macOS version of the installer downloader runs as the user who launched it. The program will |
| 97 | +save the downloaded installer to a temporary directory writable by the user. The installer |
| 98 | +downloader will then verify the checksum of the file and launch it if it matches. This leaves |
| 99 | +a possible Time-of-Check, Time-of-Use (TOCTOU) attack vector. Any program running as the the same |
| 100 | +user can replace the installer downloader between the time it was verified and it was launched. |
| 101 | +Causing the installer downloader to launch a potentially malicious installer. |
| 102 | + |
| 103 | +Mullvad was aware of this TOCTOU attack vector from the start. We did not classify it as within |
| 104 | +the threat model. If malicious code runs as your user account, it could just as well have replaced |
| 105 | +the installer downloader before it was even launched. |
| 106 | + |
| 107 | +The audit report points out that we have written [code comments] saying that by storing the |
| 108 | +installer in a directory with a randomized name, we mitigate the TOCTOU. This is an |
| 109 | +unfortunate formulation in the documentation only. We (Mullvad) never meant that this fully |
| 110 | +protects against the attack. It can make the attack slightly harder to carry out, but nothing more. |
| 111 | + |
| 112 | +We have updated the documentation to not make invalid claims about its security properties: |
| 113 | +[PR #7858] and [PR #7889]. We will not make further adjustments at this time, since the attack |
| 114 | +is not in scope for the threat model. |
| 115 | + |
| 116 | +[code comments]: https://github.com/mullvad/mullvadvpn-app/blob/1cb7935700827140f6430030033549c4d5cb2fb1/installer-downloader/src/temp.rs#L11-L17 |
| 117 | +[PR #7858]: https://github.com/mullvad/mullvadvpn-app/pull/7858 |
| 118 | +[PR #7889]: https://github.com/mullvad/mullvadvpn-app/pull/7889 |
| 119 | + |
| 120 | +### 3.4 `thread_rng()` is deprecated in latest rand version (NOTE) |
| 121 | + |
| 122 | +The audit points out that we use `rand::thread_rng()` as random number generator, and that it is |
| 123 | +deprecated in a version of the `rand` library newer than the one we are currently using. |
| 124 | + |
| 125 | +There is nothing wrong or insecure about `thread_rng` in the version we are using, `rand` |
| 126 | +just decided to rework the API a little bit for their `0.9.0` release. |
| 127 | + |
| 128 | +We will make sure to use a secure CSPRNG once we upgrade this library in the future. |
| 129 | + |
| 130 | + |
| 131 | +## Last words |
| 132 | + |
| 133 | +We want to thank Assured for the valuable feedback on the update protocol and the professional |
| 134 | +source code audit of the code related to the software update mechanisms. |
0 commit comments