Alarm raised over Mozilla VPN: Wonky authorization check lets users cause havoc

SUSE security engineer goes public on unfixed client hole after disclosure drama

Updated A security engineer at Linux distro maker SUSE has published an advisory for a flaw in the Mozilla VPN client for Linux that has yet to be addressed in a publicly released fix because the disclosure process went off the rails.

In a post to the Openwall security mailing list, Matthias Gerstner describes a broken authentication check in Mozilla VPN client v2.14.1, released on May 30.

Essentially, the client can be exploited by any user on a system to, among other things, configure their own arbitrary VPN setup, redirect network traffic to outside parties, and break existing VPN setups. That's no good on shared computers with multiple users.

The issue was identified, says Gerstner, when an openSUSE community manager wanted to add the Mozilla VPN client to openSUSE Tumbleweed, a Linux distribution. The software was reviewed by the SUSE security team, a standard procedure, and they found the VPN software "contains a privileged D-Bus service running as root and a Polkit policy."

Polkit, formerly PolicyKit, is an authorization API for privileged programs. The SUSE security team noticed that the privileged mozillavpn linuxdaemon process had incorrect authorization logic.

Citing the listed XML-based Polkit policy declarations, Gerstner observed that the way the authentication check is written, the code asks Polkit to determine whether the privileged Mozilla VPN D-Bus service – rather than the user – is authorized to perform the action.

Since the D-Bus service runs with root privileges, the authorization check always returns true. That means the D-Bus call will work for any user account, regardless of privileges.

"The impact is that arbitrary local users can configure arbitrary VPN setups using Mozilla VPN and thus possibly redirect network traffic to malicious parties, pretend that a secure VPN is present while it actually isn't, perform a denial-of-service against an existing VPN connection or other integrity violations," said Gerstner.

Gerstner also calls out the absence of any Polkit authorization checks for various other D-Bus methods like getLogs(), cleanupLogs(), runningApps(), firewallApp(), firewallClear(), and deactivate(). These all execute functions that should be authorized. For example, it's fundamentally insecure to let any local account on a system deactivate another user's VPN.

Responsible disclosure needs to work both ways

Polkit itself had a recent significant security issue, but the Mozilla VPN vulnerability is the result of improper implementation. What makes it noteworthy is the way the disclosure was handled.

According to Gerstner, the issue was privately disclosed to Mozilla on May 4, and SUSE heard nothing further until June 12, when its security team learned the flaw had been disclosed in a GitHub pull request to the Mozilla VPN repo.

"We asked upstream once more what their intentions are regarding coordinated disclosure but did not get a proper response," said Gerstner.

Nonetheless, the SUSE team waited until Thursday, August 3, after 90 days had elapsed, to post publicly about the flaw, which Mozilla has now assigned CVE-2023-4104.

Gerstner says Mozilla VPN plans to stop using Polkit authentication completely in the upcoming v2.16.0 release, which does nothing to change the fact that all the D-Bus APIs remain unauthenticated and usable by any local user.

Improved authorization is expected in v2.17.0 – which does not yet have a release date – by requiring the D-Bus caller to have the CAP_NET_ADMIN permission, or the UID associated with the user who activated the connection. This is expected in one or two months.

As for the other potential information leaks described in the post, Gerstner says there is no word on how or when those will be addressed.

Asked to comment, a Mozilla spokesperson told The Register that "while the timing is uncertain," the organization anticipates sharing more information on Monday. ®

Updated to add

"We acknowledge that our communication regarding this bug report could have been more precise, given our commitment to be responsive and collaborative partners," a Mozilla spokesperson said in a statement to The Register.

"We have been working to implement improvements to address the issue, and as a result, will advance the timing of this fix in a special release of 2.16.1 for Linux on August 11th, 2023."

Mozilla has also made public the initial bug report

More about


Send us news

Other stories you might like