1598562 - Prevent Remote Settings server URL to be modified in release

Status: RESOLVED FIXED

(Firefox :: Remote Settings Client, enhancement)

Description

[Mathieu Leplatre [:leplatrem]]

In order to prevent attackers to temper with Remote Settings configuration, we could prevent the server URL to be changed in release builds.

Comment 1

[Mathieu Leplatre [:leplatrem]]

Attachment: Bug 1598562 - Prevent Remote Settings server URL to be modified in release

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6e7d21f9e8ef
Prevent Remote Settings server URL to be modified in release r=Gijs

Comment 3

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/6e7d21f9e8ef

Comment 4

[Daniel Varga [:dvarga]]

Backed out changeset 6e7d21f9e8ef (Bug 1598562) for causing Bug 1600450 in 72 beta
Backout link: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=3b2676056584688eb47f8ad9b2b4070fe7ca00c8

Comment 5

[:Gijs (he/him)]

This is going to get backed out in bug 1600450 because of perma-orange of a ton of xpcshell tests in beta.

To fix this, we should probably flip the allow viruses pref for the relevant test directories.

The best option is probably sticking it in xpcshell head.js for those directories. Based on https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&selectedJob=278883034&resultStatus=testfailed%2Cbusted%2Cexception&revision=45db0a68a4e072d658226138e201aa767cd01cba&searchStr=xpc , and thus https://treeherder.mozilla.org/testview.html?repo=try&revision=45db0a68a4e072d658226138e201aa767cd01cba the directories are:

browser/components/aboutlogins/tests/unit/
browser/components/extensions/test/xpcshell/
docshell/test/unit/
image/test/unit/
netwerk/test/unit/
netwerk/test/unit_ipc/
services/settings/test/unit/
toolkit/components/extensions/test/xpcshell/
toolkit/components/search/tests/xpcshell/
toolkit/components/telemetry/tests/unit/
toolkit/components/url-classifier/tests/unit/
toolkit/modules/tests/xpcshell/
toolkit/mozapps/extensions/test/xpcshell/rs-blocklist/
widget/headless/tests/

This would unfortunately change a bunch of behaviour. Other options include:

0. try to set this pref for all of xpcshell. I suspect this will be a pain, but I could be wrong...
1. add a separate (cached) check to replace Cu.isInAutomation that just checks the MOZ_DISABLE_NONLOCAL_CONNECTIONS env var (ie a JS equivalent of xpc::AreNonLocalConnectionsDisabled())
2. add a separate check that just checks for xpcshell, ie:

let env = Cc["@mozilla.org/process/environment;1"].getService(
  Ci.nsIEnvironment
);
const isXpcshell = env.exists("XPCSHELL_TEST_PROFILE_DIR");

The last part is apparently what we're doing everywhere else, so might be the safest bet here. "everywhere else" - so much so that at this point, it's a cargo-culted monstrosity that we should get rid of ( bug 1598804 ).

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backout merged https://hg.mozilla.org/mozilla-central/rev/3b2676056584

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0e4aef99fe4b
Prevent Remote Settings server URL to be modified in release r=Gijs

Comment 8

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/666b11c33fee
Backed out changeset 0e4aef99fe4b for causing browser-chrome failures in browser_tabMatchesInAwesomebar.js CLOSED TREE

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f72073d5c502
Prevent Remote Settings server URL to be modified in release r=Gijs

Comment 10

[Alexandru Michis [:malexandru]]

Backed out since we saw a streak of failures leading from the push above, but wasn't caused by it.
Relanded.

Comment 11

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/f72073d5c502

Comment 12

[daniel]

How could this be implemented? With that, it isn't possible to make firefox not "phone home": Every standard release will contact "firefox.settings.services.mozilla.com", regardless of the services.settings.server setting. I'm all for making firefox beeing somewhat tamper-proof, but this takes a important decision away from the user. At least a setting which disables the settings server should be neccessary.

Comment 13

[Mathieu Leplatre [:leplatrem]]

How could this be implemented?

I participated in that decision. That seemed to be the most reasonable way to prevent hijacking of users profiles (pretty common practice unfortunately). Remote Settings controls critical parts of Firefox and the user preferences can easily be tampered.

With that, it isn't possible to make firefox not "phone home" [...] at least a setting which disables the settings server should be neccessary.

I understand your concerns. I'd be happy to find a convenient and secure alternative to this!
Currently, if you run Firefox with a specific environment variable, the preference value will be read. But we can do better, this was not meant to be a user flag.

Also, if your goal is to disable any connection with the Remote Settings server, then you can also modify your system hosts file...

Comment 14

[daniel]

I understand your concerns. I'd be happy to find a convenient and secure alternative to this!
Currently, if you run Firefox with a specific environment variable, the preference value will be read. But we can do better, this was not meant to be a user flag.

Also, if your goal is to disable any connection with the Remote Settings server, then you can also modify your system hosts file...

Thank you for your response. Blocking it using the hosts file is surely possible, but not very handy; for example if you move your profile directory to a new Computer, you would have to add it again to the hosts file; the same applies for the env. variable.

I suggest to add a setting ''services.settings.enabled'' which disables the remote settings or to disable the remote settings if ''services.settings.poll_interval'' is zero or negative.

Comment 15

[Mathieu Leplatre [:leplatrem]]

I suggest to add a setting ''services.settings.enabled'' which disables the remote settings or to disable the remote settings if ''services.settings.poll_interval'' is zero or negative.

Of course, that would make it very handy for users to disable it. But unfortunately it would also allow hijackers to tamper with the local DB of remote settings and disable its updates. And that's exactly why we did this patch in the first place.