24 ms·

Mozilla VPN: CVE-2023-4104: vpndaemon wrongly implements Polkit authentication

262 points by rkta 3y ago

Aachen 3y ago
Impact: local users on the system, including dummy service users like 'nobody', can perform actions on a running Mozilla VPN daemon via D-Bus, including activating the VPN with a server of the attacker's choice, deactivating the VPN, obtaining log files to see when the user historically activated the VPN, and clearing log files So you need to have a local shell on the system of the user you want to attack. Not cool, it violates permission boundaries that are there for a reason, but the headline sounded to me like a remote authentication bypass (I'm not into the whole D-Bus/Polkit thing) which this is not
- pjmlp 3y ago
  This is a great attack vector on corporations that use shared servers for their users.
  - makkes 3y ago
    I don't think they would be running the Mozilla VPN client on those servers, though.
- lapinot 3y ago
  Local unprivileged shell is not an unreasonable thing to get on linux since most people are building random software regularly. Among the things i know i should be doing but i don't: using a dedicated user for building everything; sandboxing the build process using some bwrap/container.
  - insanitybit 3y ago
    Privesc is also trivial on desktop linux :P so if your barrier is "but I'm an unprivileged user" it's likely not enough. You need a proper sandbox if you want to make escalation difficult. ex: Desktop Linux's running X have a trivial escalation path; any program can read all keystrokes across all users. You type your sudo password in, you're screwed. Or if the attacker is running as your user they can just modify your bashrc, aliases, etc, to do a whole bunch of things - like having `sudo` go to an attacker controlled binary - that one will work on the server, too! So yeah sandboxing builds is super important because "unprivileged users" are almost always one trivial step away from full root.
    - tedunangst 3y ago
      There's no reason for your build user to require access to X.
      - bravetraveler 3y ago
        Or even most (all) namespaces of the host! Beyond just minding privileges of the user, building in a container/chroot/etc is nice from a cleanliness/repeatability perspective. For those interested in the Fedora packaging ecosystem -- look into fedpkg and mock https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/ https://docs.fedoraproject.org/en-US/package-maintainers/Pac...
TylerE 3y ago
NB: < on Linux >
- rkta 3y ago
  It's in the original headline, but I had to cut it because it was too long.
  - Anthony-G 3y ago
    You made the right call. Polkit is most commonly deployed on modern GNU/Linux distributions so the “on Linux” is mostly redundant. On a related note, Polkit, itself, has had its own privilege escalation problems: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4034 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4034 https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034 https://blog.qualys.com/vulnerabilities-threat-research/2022...
- WhyNotHugo 3y ago
  Polkit only runs on GNU/Linux with systemd anyway.
  - TylerE 3y ago
    One could easily not know that, given how many SomethingKits there are in The Apple ecosystem.
  - Arnavion 3y ago
    polkit does not require systemd.
veave 3y ago
In case you needed any more excuses to switch to using mullvad directly.
- smolyeet 3y ago
  Unless you need port forwarding. I switched to ovpn for that very reason.
Vogtinator 3y ago
Looks like another case of a vulnerability which was handled poorly by upstream: Bad/insufficient communication and multiple embargo violations. Ultimately this means there is no fix available yet and no ETA when there will be one.
p-e-w 3y ago
> We publish this report today, because the maximum embargo period of 90 days we offer has been exceeded. Most of the issues mentioned in this report are currently not addressed by upstream, as is outlined in more detail below. > [...] > 2023-05-04: We privately shared the findings with security@...illa.org, offering coordinated disclosure according to the openSUSE disclosure policy. > Until 2023-06-12: There has been a lack of communication by upstream. Relevant questions about the disclosure process remained unanswered, there was no formal reply to our report and no wishes have been expressed about how to continue the coordinated disclosure, or what the next steps would be. > 2023-06-12: We learned that the embargo over this issue was violated by upstream via a GitHub PR [3] and, inspired by that, our community packager followed suit via another GitHub PR [5]. What a complete clusterfuck. It's unbelievable that in 2023, a company of Mozilla's stature appears to have no proper processes in place for handling serious security vulnerabilities even when they are being reported to them (for free!) by cooperative third parties. This taints the image of the entire product in my view.
- TylerE 3y ago
  In my eyes, at least, Mozilla has been tainted since the Pocket fiasco, if not before. That's when they made it obvious they'd sell their users off for a buck.
  - p-e-w 3y ago
    Pocket is crapware, and I don't want it in my browser, and the way they forced it upon me left a bad aftertaste, but I still don't see how it constitutes "selling out their users". Pocket is actually owned by Mozilla. It's not like the data is going elsewhere or something.
    - Knee_Pain 3y ago
      The funny thing is that even though it's a Mozilla product now and even though it's somehow "integrated" in the browser, I still have to log into it separately regardless of the fact that I am already logged with with Firefox Sync
Barrin92 3y ago
>an openSUSE community packager wanted to add the Mozilla VPN client [1] to openSUSE Tumbleweed, which required a review [2] by the SUSE security team, as it contains a privileged D-Bus service running as root and a Polkit policy. and this is why I tell everyone who wants to run a rolling release distro to go with Opensuse rather than distros where people just install random packages from community repositories. They are so underrated given the scrutiny they put into their packaging and build process.
WhyNotHugo 3y ago
These are some nasty implementation bugs, but honestly, there are some way more serious design issues at hand here. A user-configured VPN should not run as root and affect networking for the entire system; the whole VPN process should run in its own network namespace with no more privileges beyond those of the user activating it. Processes that need to use the VPN (rather than clearnet) should be attached to that same network namespace. If necessary, you can even avoid attaching a NAT (e.g.: slirp4netns) to the namespace so that if the VPN dies there is no data leakage. I get that running things as root has a bit more performance, but compromising on security for the sake of performance doesn't sound like the right approach for this kind of software.
- Joker_vD 3y ago
  Yeah, for some reason almost all user-specific customization of network-connectivity (VPN, DNS, etc) requires root privileges.
  - Vogtinator 3y ago
    Yeah, because it affects networking in the entire system. If some pam session module were to set up its own network namespace that is shared by all user processes after login, this could be (mostly) solved. The result would be some surprising behaviour though, as processes outside have a possibly vastly different view of the network.
    - Joker_vD 3y ago
      Just like containers?.. I don't see how that's surprising or undesirable.
      - Vogtinator 3y ago
        Not necessary undesirable, but definitely surprising as it's a major change from the current behaviour.
- insanitybit 3y ago
alrlroipsp 3y ago
The summary seems to ignore upstream. They did infact removed polkit : https://github.com/mozilla-mobile/mozilla-vpn-client/pull/7055 https://github.com/mozilla-mobile/mozilla-vpn-client/pull/70... refactor auth using D-Bus: https://github.com/mozilla-mobile/mozilla-vpn-client/pull/7110 https://github.com/mozilla-mobile/mozilla-vpn-client/pull/71... These are why author's PR was dropped.
NoZebra120vClip 3y ago
"Open" is a great marketing term to signify to geeks that you're hip to the whole movement thing, and "Wall" of course is a classic Cybersecurity term that is an instantly recognizable part of "firewall", but when you make a portmanteau into "OpenWall" and a big gaping security hole is revealed, surely the irony is not lost on us.
- tedunangst 3y ago
  You are aware that openwall doesn't make the mozilla vpn, right?
- segfaultbuserr 3y ago
  OpenWall is a highly-respected security research and hacking project from the early 2000s. This group was responsible for revealing numerous 0days during the chaotic days of the early Web, as well as developing exploit mitigation techniques. These days it's mainly known for hosting security-related mailing lists such as oss-security and kernel-hardening, widely read by security researchers and kernel developers. The name is more than appropriate. It's not the developer of Mozilla VPN.
insanitybit 3y ago
A major action item here from Mozilla would be to bring this VPN under the same policies and teams that manage Firefox's security issues - or standardize the policies across the company and ensure products are staffed for it (if there is a reason to avoid centralizing that to the team). I would never expect such poor handling from a browser vendor.
Tammy945 3y ago
[dead]

262 points by rkta 3y ago

Impact: local users on the system, including dummy service users like 'nobody', can perform actions on a running Mozilla VPN daemon via D-Bus, including activating the VPN with a server of the attacker's choice, deactivating the VPN, obtaining log files to see when the user historically activated the VPN, and clearing log files So you need to have a local shell on the system of the user you want to attack. Not cool, it violates permission boundaries that are there for a reason, but the headline sounded to me like a remote authentication bypass (I'm not into the whole D-Bus/Polkit thing) which this is not

pjmlp 3y ago
This is a great attack vector on corporations that use shared servers for their users.
- makkes 3y ago
  I don't think they would be running the Mozilla VPN client on those servers, though.
lapinot 3y ago
Local unprivileged shell is not an unreasonable thing to get on linux since most people are building random software regularly. Among the things i know i should be doing but i don't: using a dedicated user for building everything; sandboxing the build process using some bwrap/container.
- insanitybit 3y ago
  Privesc is also trivial on desktop linux :P so if your barrier is "but I'm an unprivileged user" it's likely not enough. You need a proper sandbox if you want to make escalation difficult. ex: Desktop Linux's running X have a trivial escalation path; any program can read all keystrokes across all users. You type your sudo password in, you're screwed. Or if the attacker is running as your user they can just modify your bashrc, aliases, etc, to do a whole bunch of things - like having `sudo` go to an attacker controlled binary - that one will work on the server, too! So yeah sandboxing builds is super important because "unprivileged users" are almost always one trivial step away from full root.
  - tedunangst 3y ago
    There's no reason for your build user to require access to X.
    - bravetraveler 3y ago
      Or even most (all) namespaces of the host! Beyond just minding privileges of the user, building in a container/chroot/etc is nice from a cleanliness/repeatability perspective. For those interested in the Fedora packaging ecosystem -- look into fedpkg and mock https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/ https://docs.fedoraproject.org/en-US/package-maintainers/Pac...

TylerE 3y ago

NB: < on Linux >

rkta 3y ago
It's in the original headline, but I had to cut it because it was too long.
- Anthony-G 3y ago
  You made the right call. Polkit is most commonly deployed on modern GNU/Linux distributions so the “on Linux” is mostly redundant. On a related note, Polkit, itself, has had its own privilege escalation problems: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4034 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4034 https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034 https://blog.qualys.com/vulnerabilities-threat-research/2022...
WhyNotHugo 3y ago
Polkit only runs on GNU/Linux with systemd anyway.
- TylerE 3y ago
  One could easily not know that, given how many SomethingKits there are in The Apple ecosystem.
- Arnavion 3y ago
  polkit does not require systemd.

veave 3y ago

In case you needed any more excuses to switch to using mullvad directly.

smolyeet 3y ago
Unless you need port forwarding. I switched to ovpn for that very reason.

Vogtinator 3y ago

Looks like another case of a vulnerability which was handled poorly by upstream: Bad/insufficient communication and multiple embargo violations. Ultimately this means there is no fix available yet and no ETA when there will be one.

p-e-w 3y ago

> We publish this report today, because the maximum embargo period of 90 days we offer has been exceeded. Most of the issues mentioned in this report are currently not addressed by upstream, as is outlined in more detail below. > [...] > 2023-05-04: We privately shared the findings with security@...illa.org, offering coordinated disclosure according to the openSUSE disclosure policy. > Until 2023-06-12: There has been a lack of communication by upstream. Relevant questions about the disclosure process remained unanswered, there was no formal reply to our report and no wishes have been expressed about how to continue the coordinated disclosure, or what the next steps would be. > 2023-06-12: We learned that the embargo over this issue was violated by upstream via a GitHub PR [3] and, inspired by that, our community packager followed suit via another GitHub PR [5]. What a complete clusterfuck. It's unbelievable that in 2023, a company of Mozilla's stature appears to have no proper processes in place for handling serious security vulnerabilities even when they are being reported to them (for free!) by cooperative third parties. This taints the image of the entire product in my view.

TylerE 3y ago
In my eyes, at least, Mozilla has been tainted since the Pocket fiasco, if not before. That's when they made it obvious they'd sell their users off for a buck.
- p-e-w 3y ago
  Pocket is crapware, and I don't want it in my browser, and the way they forced it upon me left a bad aftertaste, but I still don't see how it constitutes "selling out their users". Pocket is actually owned by Mozilla. It's not like the data is going elsewhere or something.
  - Knee_Pain 3y ago
    The funny thing is that even though it's a Mozilla product now and even though it's somehow "integrated" in the browser, I still have to log into it separately regardless of the fact that I am already logged with with Firefox Sync

Barrin92 3y ago

>an openSUSE community packager wanted to add the Mozilla VPN client [1] to openSUSE Tumbleweed, which required a review [2] by the SUSE security team, as it contains a privileged D-Bus service running as root and a Polkit policy. and this is why I tell everyone who wants to run a rolling release distro to go with Opensuse rather than distros where people just install random packages from community repositories. They are so underrated given the scrutiny they put into their packaging and build process.

WhyNotHugo 3y ago

These are some nasty implementation bugs, but honestly, there are some way more serious design issues at hand here. A user-configured VPN should not run as root and affect networking for the entire system; the whole VPN process should run in its own network namespace with no more privileges beyond those of the user activating it. Processes that need to use the VPN (rather than clearnet) should be attached to that same network namespace. If necessary, you can even avoid attaching a NAT (e.g.: slirp4netns) to the namespace so that if the VPN dies there is no data leakage. I get that running things as root has a bit more performance, but compromising on security for the sake of performance doesn't sound like the right approach for this kind of software.

Joker_vD 3y ago
Yeah, for some reason almost all user-specific customization of network-connectivity (VPN, DNS, etc) requires root privileges.
- Vogtinator 3y ago
  Yeah, because it affects networking in the entire system. If some pam session module were to set up its own network namespace that is shared by all user processes after login, this could be (mostly) solved. The result would be some surprising behaviour though, as processes outside have a possibly vastly different view of the network.
  - Joker_vD 3y ago
    Just like containers?.. I don't see how that's surprising or undesirable.
    - Vogtinator 3y ago
      Not necessary undesirable, but definitely surprising as it's a major change from the current behaviour.
insanitybit 3y ago

alrlroipsp 3y ago

The summary seems to ignore upstream. They did infact removed polkit : https://github.com/mozilla-mobile/mozilla-vpn-client/pull/7055 https://github.com/mozilla-mobile/mozilla-vpn-client/pull/70... refactor auth using D-Bus: https://github.com/mozilla-mobile/mozilla-vpn-client/pull/7110 https://github.com/mozilla-mobile/mozilla-vpn-client/pull/71... These are why author's PR was dropped.

NoZebra120vClip 3y ago

"Open" is a great marketing term to signify to geeks that you're hip to the whole movement thing, and "Wall" of course is a classic Cybersecurity term that is an instantly recognizable part of "firewall", but when you make a portmanteau into "OpenWall" and a big gaping security hole is revealed, surely the irony is not lost on us.

tedunangst 3y ago
You are aware that openwall doesn't make the mozilla vpn, right?
segfaultbuserr 3y ago
OpenWall is a highly-respected security research and hacking project from the early 2000s. This group was responsible for revealing numerous 0days during the chaotic days of the early Web, as well as developing exploit mitigation techniques. These days it's mainly known for hosting security-related mailing lists such as oss-security and kernel-hardening, widely read by security researchers and kernel developers. The name is more than appropriate. It's not the developer of Mozilla VPN.

insanitybit 3y ago

A major action item here from Mozilla would be to bring this VPN under the same policies and teams that manage Firefox's security issues - or standardize the policies across the company and ensure products are staffed for it (if there is a reason to avoid centralizing that to the team). I would never expect such poor handling from a browser vendor.

Tammy945 3y ago

[dead]