Skip to content

Commit 0a0aaca

Browse files
committed
Add Assured's security audit report of the installer downloader
1 parent e3d6963 commit 0a0aaca

3 files changed

+135
-0
lines changed
Binary file not shown.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
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.

audits/README.md

+1
Original file line numberDiff line numberDiff line change
@@ -17,3 +17,4 @@ performed on this app so far:
1717
Apart from the biannual audits mentioned above, we've also conducted the the following:
1818

1919
* [2025-02-24 - NCC Group Mobile Application Security Assessment (MASA) of the Android app](./2025-02-24-nccgroup-android-masa.md)
20+
* [2025-03-20 - Audit of the installer downloader by Assured](./2025-03-20-assured-installer-downloader.md)

0 commit comments

Comments
 (0)