> 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.<p>> [...]<p>> 2023-05-04: We privately shared the findings with security@...illa.org,
offering coordinated disclosure according to the openSUSE disclosure policy.<p>> 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.<p>> 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].<p>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.<p>This taints the image of the entire product in my view.
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<p>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
>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.<p>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.
The summary seems to ignore upstream.<p>They did infact<p>removed polkit : <a href="https://github.com/mozilla-mobile/mozilla-vpn-client/pull/7055">https://github.com/mozilla-mobile/mozilla-vpn-client/pull/70...</a><p>refactor auth using D-Bus: <a href="https://github.com/mozilla-mobile/mozilla-vpn-client/pull/7110">https://github.com/mozilla-mobile/mozilla-vpn-client/pull/71...</a><p>These are why author's PR was dropped.
These are some nasty implementation bugs, but honestly, there are some way more serious design issues at hand here.<p>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.<p>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.
Looks like another case of a vulnerability which was handled poorly by upstream: Bad/insufficient communication and multiple embargo violations.<p>Ultimately this means there is no fix available yet and no ETA when there will be one.
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.
"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.