1313689 - Certificate Exception Mechanism is too Privileged

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[raffprta]

Attachment: Certificate_Exception.pdf

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36
Firefox for Android

Steps to reproduce:

Note: This attack is present in the Android version of Firefox too (no root required).

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build Identifier: 20161019084923

Dear Mozilla,

I am writing from Newcastle University, as a current PhD student with some information regarding the security within the design decisions taken in the certificate exception mechanism in Firefox which we believe detrimental to a user's browsing experience.

The design of the certificate exception mechanism is too privileged, in the sense that it is easy for an Extension built with Add-On SDK to modify the file: cert_override.txt located in the browser's user profile, to silently include their own certificate exceptions. 

For example, a malicious extension is uploaded disguised as a benign certificate exception management app. 

The extension then will remotely load in a certificate which may contain domain mismatches, self-signed authenticity, weak algorithms or is well past its expiration, and be added to the cert_override.txt file as no write protection, or more pertinently, user confirmation dialog is enabled.

Attached to this bug report is a section from a currently unpublished paper detailing the attack.

Best Regards.


Actual results:

In the presence of a malicious extension, which has evaded the vetting process, appending to the cert_override.txt file allows certificate exceptions to be *silently* added, which are then activated silently on a browser restart (or, in the Android version, closing a tab).

Though our research took place before the latest version of Firefox, we have verified the results in that the exceptions can still be added however now (unlike the attached paper) the URL does not show a green lock for the browser version. The site can still be accessed, however, without the "Confirm security exception" warning showing up. The android version, however, continues to show a green lock once the exception is added. This may result in a major breach in the user's certificate management and secure site access.


Expected results:

We suggest adding a dialog for user confirmation when an extension attempts to write over to this file, or adopting a session based certificate exception schema as is used by Chrome. 

Furthermore, the Android version should not show a green lock when certificate exceptions are added.

Comment 1

[Daniel Veditz [:dveditz]]

Add-ons currently can do anything Firefox can do, including intercepting the "Bad Cert" dialog and granting exceptions -- no need to directly overwrite the exceptions file. This is not theoretical: existing add-ons do this for various legitimate (and less so) reasons. It's more common for such add-ons to add their own root certificate so that all traffic can be MITM'd; for example anti-virus products do this.

We are slowly phasing out "old-style" add-ons in favor of "WebExtensions" which have far more limited abilities.

Comment 2

[:Gijs (he/him)]

Beyond the move to web extensions there's little else we can do to lock down add-ons, so I don't think this is worth keeping open for that on its own. Cc'ing Andy, Jorge and Andreas so they're aware. I don't think the ecosystem really has room for mitigation strategies (add-on sdk add-ons are too require(chrome) happy to really do anything, and non-sdk ones too prevalent, too), so I'm not sure keeping this in Fx::Security makes sense.


If we generalize this beyond add-ons, it is not possible to both have working exception UI inside Firefox with exceptions that outlast the browser session, and to defend against an attacker with privileges to run local apps like Firefox. Such an attacker would always be able to modify whatever storage we use to store exceptions, just like Firefox is able to modify it.

The suggested remediation (beyond warning for file writes, which is impractical for both outside apps and add-ons) from comment #0 is to no longer have exceptions that outlast the browser session (which it suggests is what Chrome does - I haven't checked).

Such a change effectively would mean moving certoverride.txt to the browser install dir and locking it down so you'd need root to change it (if fx was installed as root), and for exceptions made using browser UI to not persist. That would be a PSM change, so I'm moving this there - but that might be a dupe?

Comment 3

[Andy McKay]

Thanks for the heads up, I would agree that moving to WebExtensions is our best strategy.

Comment 4

[Kris Maglione [:kmag]]

We already have review policies in place that require any access to the certificate trust DB to be approved by an admin reviewer. We could add some more checks to the validator to try to detect direct access to the DB, or to the relevant parts of the UI, but that really only helps with good faith submissions.

Beyond that, there's not really much we can do. Even if we don't allow exceptions to last beyond the current session, legacy extensions could just re-add them after restart to achieve the same effect.

So I think we should probably just close this bug, and consider filing a new one for the validator.

Comment 5

[:Gijs (he/him)]

(In reply to Kris Maglione [:kmag] from comment #4)
> Even if we don't allow
> exceptions to last beyond the current session, legacy extensions could just
> re-add them after restart to achieve the same effect.

Right, but assuming we won't add an API to do this (or arbitrary file access without user confirmations) to webextensions, that possibility goes away when legacy add-ons go to die.

However, we would still need to switch from permanent to session-based exceptions to defeat a local non-admin-user-level-only threat, which at least seems worth explicitly making a decision about, which could be done in this bug? If there is already a separate bug about such a change, I agree it'd make sense to just close this bug.

Comment 6

[raffprta]

I agree that moving to WebExtensions seems to be the natural fix to this, at the time we conducted our study, they were still being developed so we didn't focus on them. 

Moving the certificate exceptions file to Firefox's install directory seems like an excellent decision to implement a session based system that will thwart against non-root malware when the threat of legacy/add-on sdk extensions is removed.

BTW: Have you taken a look at an additional comment I made, regarding certificate exceptions showing a "Green Lock" when added using Firefox for Android? Is this intended behavior, as now manually added certificate exceptions don't show a green lock on the desktop browser.

Comment 7

[:Gijs (he/him)]

(In reply to raffprta from comment #6)
> BTW: Have you taken a look at an additional comment I made, regarding
> certificate exceptions showing a "Green Lock" when added using Firefox for
> Android? Is this intended behavior, as now manually added certificate
> exceptions don't show a green lock on the desktop browser.

--> Sebastian, do we have a bug on file for this and if not, assuming you think this would be useful, could you create one?

Comment 8

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Gijs Kruitbosch from comment #7)
> --> Sebastian, do we have a bug on file for this and if not, assuming you
> think this would be useful, could you create one?

Thanks for flagging me. I filed bug 1314563. We should definitely investigate why there's a difference here.

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

The ability to add permanent certificate error overrides is a feature (it enables a sort of pinning whereby if a user trusts a certificate for a site once, Firefox will automatically trust it if it encounters the exact same certificate on that site in the future). There are some improvements we can make (e.g. bug 399910), but I don't see us removing this ability. Given that, I don't really see a way of locking down the backing file so that only root/an admin can change it (if we do that, how can the user change it?). So, in terms of how this mechanism works, I think this is a wontfix.