1802878 - zScaler is enabling enterprise roots in firefox to MITM connections using prefs from enterprise policy cfg file without user approval

Status: UNCONFIRMED

(Firefox :: Security, defect)

Description

[antonio]

Attachment: zscaler.cfg and default/prefs/... injected by zScaler

Steps to reproduce:

This is on Windows 10 Enterprise 21H2 / Mozilla Firefox 107.0 (64-bit)

• Ensure zScaler ZIA is installed in your computer (probably by your company).
• Install firefox.
• Ensure "security.enterprise_roots.auto-enabled" and "security.enterprise_roots.enabled" are both set to false.
• Visit a website not whitelisted by zScaler.
• zScaler sets "security.enterprise_roots.auto-enabled" and "security.enterprise_roots.enabled" to true.

This happens both if Firefox is installed in a system directory (C:\Program Files...) or in a custom set directory (C:\Users\user...).

zScaler also adds a "zscaler.cfg" file in the browser installation directory, as well as some files in the "defaults/pref" subdirectory (attached).

Actual results:

Firefox silently starts trusting the zScaler CA certificates, that are injected in the browser from a "software security device".

As a consequence zScaler successfully sets itself as a Man-In-The-Middle, intercepting all communications without a previous user notification nor consent.

Expected results:

The user should be notified, and probably should consent, the injection of a new "software security device" that silently installs and trusts on CA certificates.

Otherwise "bad guys" could use the same technique as zScaler to set up MITM attacks on firefox.

Comment 1

[antonio]

"zscaler.cfg" is encoded by default, the decoded version is:

---

// First line is always comment
lockPref("network.proxy.type", 0);

Comment 2

[:Gijs (he/him)]

Can you provide some more context? What is "zScaler", and does it inject in some way while Firefox is running, or does it require a browser restart? (Given step 3 says these prefs are false, and step 5 says the pref values change - I'm not aware of a way that the injected prefs code would be read without a restart, so if that is happening I'd like to understand more both about how that is taking place and when / based on what activity zScaler decides to do it... does zScaler have an add-on in the browser if you look at about:support?)

Comment 3

[antonio]

Hi again.
Apologies for not clarifying.

• zScaler ZIA (https://help.zscaler.com/zia) is a cibersecurity solution by zScaler that sets up a corporate MITM.
• The injection is performed while Firefox is running. No browser restart required.
• zScaler is installed as a Windows service, not as a firefox plugin.
• I'm attaching a PDF with my current about:support page (spanish, I'm afraid).
• The only thing I see related to zScaler in "about:support" is a "security.pki.mitm_canary_issuer" setting.

Comment 4

[antonio]

Attachment: about-support.pdf

Comment 5

[antonio]

This document contains a more detailed description of zScaler's ZIA MITM (PDF link) https://help.zscaler.com/downloads/zia/reference-architecture/tlsssl-inspection-zscaler-internet-access/TLS-SSL-Inspection-with-Zscaler-Internet-Access.pdf

Comment 6

[Mike Kaply [:mkaply]]

If software needs to use enterprise roots, this is the recommended mechanism to do so at this time. Other Antivirus software does this as well.

I agree it's not the best solution, and I've opened a bug to do it better and provide the user a little more information (https://bugzilla.mozilla.org/show_bug.cgi?id=1732152), but if you install software and give it admin access to your machine, it is free to do pretty much anything to your machine.

It definitely should only be read at startup though.

Can you post a screenshot of your about:policies?

Comment 7

[Daniel Veditz [:dveditz]]

As Mike said, this mechanism was designed for this kind of system, because the alternative was that they were trying to hack profile files and would sometimes render the profile unusable if Firefox changed the file format or data slightly. This is, unfortunatey, the power of admin-installed services.

The lack of notice could be a problem that zScaler should address, to inform their customers that this is what they are doing.

There's an open question we've had for a while whether we should indicate a difference between when a built-in root is used or when a local root is used. Similarly, I believe we now indicate when a user has a site override (also part of the same argument).

Comment 8

[Dana Keeler (she/her) [:keeler]]

Attachment: site identity drop-down indicating a third-party root

(In reply to Daniel Veditz [:dveditz] from comment #7)

There's an open question we've had for a while whether we should indicate a difference between when a built-in root is used or when a local root is used.

FWIW, we do currently show this in the site identity drop-down when a connection uses a third-party root.

Comment 9

[antonio]

Attachment: about-policies.pdf

Comment 10

[antonio]

Attachment: amazon.png - Dropdown shows certificate is issued by a non recognized CA.

Comment 11

[antonio]

IMHO the "User trusts Firefox trusts the Truststore" is a chain of trust worth keeping.

Whenever this chain of trust is broken you should clearly warn the user, I think. A message "hidden" in a dropdown box is not good enough for me. Otherwise users's credit card numbers may end up in a zScaler/antivirus cloud all around the world whenever they buy at Amazon, for instance.

I've uploaded the "about:policies" page as PDF. To my surprise this shows a "Websense Endpoint" plugin that I cannot remove manually. Wow, this has become a can of worms!

Maybe you could also warn the user about all this "enterprise spyware" that is injected in the browser?

Comment 12

[:Gijs (he/him)]

(In reply to antonio from comment #11)

IMHO the "User trusts Firefox trusts the Truststore" is a chain of trust worth keeping.

Unfortunately, when insisting on it means "the user now can't use any of the internet with Firefox", you run into issues.

Whenever this chain of trust is broken you should clearly warn the user, I think. A message "hidden" in a dropdown box is not good enough for me. Otherwise users's credit card numbers may end up in a zScaler/antivirus cloud all around the world whenever they buy at Amazon, for instance.

If the user has an enterprise machine where they do not control what software is installed, warning users about things they cannot fix isn't really all that helpful. None of the other browsers do so either, to my knowledge, so it'd probably just end up with "ew, Firefox says my company can read my data if I use it and I can't get rid of it, I'll just use Chrome/Edge/whatever instead [which do the same thing but don't warn]." I don't see how that helps users.

The other point here is that from Firefox's perspective, it doesn't know what software told it to use the Windows root store, and it'd be unfortunate if we "warned" users for stuff they did themselves (e.g. antivirus/firewall/vpn solutions they installed themselves that MITM their own traffic).

This whole thing comes down to the fact that we cannot infer user intent from the technical fact that enterprise roots are enabled, nor can we make assumptions about users having any alternatives / options. I understand it was surprising to you, and that perhaps you have alternatives, and/or the technical know-how to understand what those alternatives might be. But "just tell the user what happened" here is not actually possible because we don't have the right information, and even if we did it would be unlikely to actually help the user.

I've uploaded the "about:policies" page as PDF. To my surprise this shows a "Websense Endpoint" plugin that I cannot remove manually. Wow, this has become a can of worms!

Maybe you could also warn the user about all this "enterprise spyware" that is injected in the browser?

Similarly, treating enterprise policies as adversarial assumes intent/controversy, as well as a user ability to do something about it, neither of which is generally true for all/most/many enterprise policies and users.

Even if it were, it's also questionable whether the warnings would be fit-for-purpose - if we showed them persistently they'd permanently hamper the browsing experience, and we cannot do a one-time warning because we can't store the "we told the user once" bit anywhere safely if the baseline assumption is that an adversary has admin access to the machine to install enterprise policies (and anyway then you hit issues with machine reuse and/or "I just clicked through that dialog why didn't you warn me harder").

TL;DR: if you give admin access on your machine to someone you treat as an adversary, the browser can do very little to help you.

Comment 13

[antonio]

(In reply to :Gijs (he/him) from comment #12)

(In reply to antonio from comment #11)

Maybe you could also warn the user about all this "enterprise spyware" that is injected in the browser?

Similarly, treating enterprise policies as adversarial assumes intent/controversy, as well as a user ability to do something about it, neither of which is generally true for all/most/many enterprise policies and users.

Even if it were, it's also questionable whether the warnings would be fit-for-purpose - if we showed them persistently they'd permanently hamper the browsing experience, and we cannot do a one-time warning because we can't store the "we told the user once" bit anywhere safely if the baseline assumption is that an adversary has admin access to the machine to install enterprise policies (and anyway then you hit issues with machine reuse and/or "I just clicked through that dialog why didn't you warn me harder").

TL;DR: if you give admin access on your machine to someone you treat as an adversary, the browser can do very little to help you.

Thanks :Gijs for the explanation. Looks reasonable to me. Time now to start hacking my own extensions then! :-).

Comment 14

[Mike Kaply [:mkaply]]

Attachment: about:preferences

We do put in a message in about:preferences (attached) that links to about:policies.

Other browsers also put a message in their main dropdown which we decided not to do (again, because it's not actionable)

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[Rares Doghi, Desktop QA]

Adding the Qa-not-actionable tag for now since we cant install the zScaler ZIA app on our end.