Closed Bug 1484929 Opened 6 years ago Closed 2 years ago

Change of trust root via signed recipe

Categories

(Core :: Security: PSM, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1769669

People

(Reporter: psiinon, Unassigned)

References

Details

(Keywords: csectype-priv-escalation, sec-moderate)

Attachments

(1 file)

As part of their security audit of Normandy, X41 have found that it is possible to use a recipe to change the configuration of the firefox 'security.content.signature.root_hash key.

A screenshot of their draft report is attached - more details will be added when we have them.
This is an issue that we've discussed in the past. Generally, Normandy doesn't have a safety checks on which preferences can be changed, and which cannot. My opinion in the past has been that any list of preferences we could restrict would be incomplete, and focusing our efforts on securing the pipeline would be more effective. (VPN on the severs, two key approval, signed recipes, short times). I still thing this is true, especially since Normandy supports add-on studies that can install add-ons that could then in theory do whatever they wanted, including changing the pref in question.

It might make sense that something so security sensitive as this root_hash shouldn't be configurable, or shouldn't be allowed to take on an arbitrary value. Hard coding it would fix this problem, but would greatly decrease our ability to isolate the stage and production Normandy servers (or anything else that uses Autograph's staging keys). We currently use different keys on stage to make sure that stage recipes (which are often extremely general) aren't generally usable. People that want to use these recipes configure Firefox to trust only the stage key and not the prod one.

I'm of the opinion that this is not a Normandy problem, since many many things could change this preference, and multiple things read from it. I don't think preventing writes to a preference is a reasonable way forward. I'm not sure what the solution is though.

I'm moving this bug to the Core/Security: PSM component, because the Mozilla build system tells me that is the component for the file that contains the content signature verifier that Normandy is using.
Group: firefox-core-security → core-security
Component: Normandy Client → Security: PSM
Product: Firefox → Core
Couldn't we create a manual "pinned" set of acceptable hashes, or do verifications on issuers for the cert or something? That would mitigate this somewhat, and wouldn't necessarily cause problems for the stage/prod switchover. We don't need to accept just any hash.
Group: core-security → dom-core-security
Flags: needinfo?(mcooper)
> Couldn't we create a manual "pinned" set of acceptable hashes,

I think something like this might work. It should fix the security problem, at least. One issue is that one of the versions of the key that we use is a very public key that is used in development on local laptops. If we allow that key, then any protection we add here would be an inconvenience to an attacker at best. If we don't a particular local workflow breaks. Perhaps we could break the workflow, and then make it simple to change as a build time config for people that really need to locally sign things.

> or do verifications on issuers for the cert 

Ultimately, I think this is what we are doing now. This preference isn't a setting for which keys to trust, it's for which *root* keys to trust. If a signature can chain back to a key with the root hash given, then it is trusted. I'm fairly sure that is the same as trusting an issuer.

I think I've armchair-cryptoed this enough though, and we really should have someone from a security team comment on this.
Flags: needinfo?(mcooper)
> One issue is that one of the versions of the key that we use is a very public key that is used in development on local laptops.

Can that key be limited to nightly/beta?

We could use the same approach as AMO: hardcode the hashes, then flip between roots using a pref (in this case, xpinstall.signatures.dev-root set to true to use the dev root).
(In reply to Julien Vehent [:ulfr] from comment #4)
> > One issue is that one of the versions of the key that we use is a very public key that is used in development on local laptops.
> 
> Can that key be limited to nightly/beta?
> 
> We could use the same approach as AMO: hardcode the hashes, then flip
> between roots using a pref (in this case, xpinstall.signatures.dev-root set
> to true to use the dev root).

That would work for Normandy. This use case isn't very common in Normandy nowadays anyways. We have stable enough APIs between components that we tend to not need to develop all the bits at once. It might be worth checking with other users of this certificate verification though.
Hey leplatrem, could you help us identify all the users of Signed Kinto/Remote Settings?  We want to get their signoff before we potentially break their workflows.


Mozilla wants Normandy to be flexible enough to prevent an allowlist of prefs from being a feasible choice - even though it'd be the most secure option.  I tend to take the attitude that a blocklist of prefs would still be advantageous, even if it is incomplete, especially since I think the implementation effort for such a thing is considerably smaller than any of the example improvements in the pipeline. (Not that I think securing the pipeline is unimportant, it definitely is very important. But one is weeks of effort and the other is a few days.)

The point about allowing arbitrary add-ons to be installed is true (and I wish that could be restricted in some way also); but doing so would hopefully be much more difficult than the pref flip. One would need to get a malicious add-on signed, or find a bug in a legitimate add-on, or find a bug in the add-on verification process.

If a blocklist of prefs one can flip via Normandy is something we'd be okay with - knowing it would likely be incomplete in some ways or bypassable via others - maybe that's better than hardcoding. Sandboxing / Belt and Suspenders and all that.
Flags: needinfo?(mathieu)
Group: dom-core-security → core-security-release
> Hey leplatrem, could you help us identify all the users of Signed Kinto/Remote Settings?  We want to get their signoff before we potentially break their workflows.

I updated the list of RemoteSettings use-cases here, and added contact info:
https://wiki.mozilla.org/Firefox/RemoteSettings#Use_Cases

I'm not sure to fully understand how we'd like to scope the issue, but as a quick note: changing the value of the ``services.settings.server`` pref to a dummy value would also result in breaking blocklisting/remote settings updates.
Flags: needinfo?(mathieu)

Removing employee no longer with company from CC list of private bugs.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: