Security

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

Send us news
36 Comments

Make-me-root 'Looney Tunables' security hole on Linux needs your attention

What's up, Doc? Try elevated permissions

Microsoft gives unexpected tutorial on how to install Linux

You may need it – Windows 10 is no longer a free upgrade

Forcing Apple to allow third-party app stores isn't enough

You're excited about Meta offering iOS apps via Facebook ads? Really?

From chaos to cadence: Celebrating two decades of Microsoft's Patch Tuesday

IT folks look back on 20 years of what is now infosec tradition

Cisco warns of critical flaw in Emergency Responder code

Hard-coded credentials strike again

US government's Login.gov turns frown upside down, now smiles on facial recognition

Authentication portal to match snaps on existing IDs with user-provided snaps

AI safety guardrails easily thwarted, security study finds

OpenAI GPT-3.5 Turbo chatbot defenses dissolve with '20 cents' of API tickling

SBF on trial: The Python code that allegedly let Alameda hedge fund spend people's FTX deposits

And Caroline Ellison says she was told by Bankman-Fried to take $10B from customer accounts

Buyer's remorse haunts 3 in 5 business software purchases

They never do tell you about the unexpected costs and overly complex implementations

Cisco zero-day bug allows router hijacking and is being actively exploited

We'd say 'Hurry up and patch' but it hasn't written one yet. While you wait, disable HTTP

Red Hat retires mailing list, leaving Linux loyalists to read between the lines

Email is just so 20th century

Squid games: 35 security holes still unpatched in proxy after 2 years, now public

We'd like to say don't panic … but maybe?