Closed Bug 1598562 Opened 3 months ago Closed 2 months ago

Prevent Remote Settings server URL to be modified in release

Categories

(Firefox :: Remote Settings Client, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
Firefox 73
Tracking Status
firefox73 --- fixed

People

(Reporter: leplatrem, Assigned: leplatrem)

References

Details

Attachments

(1 file)

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

Assignee: nobody → mathieu
Pushed by mleplatre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6e7d21f9e8ef
Prevent Remote Settings server URL to be modified in release r=Gijs
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72
Regressions: 1600450
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 72 → ---

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:

  1. try to set this pref for all of xpcshell. I suspect this will be a pain, but I could be wrong...
  2. 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())
  3. 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 ).

Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/0e4aef99fe4b
Prevent Remote Settings server URL to be modified in release r=Gijs
Backout by malexandru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/666b11c33fee
Backed out changeset 0e4aef99fe4b for causing browser-chrome failures in browser_tabMatchesInAwesomebar.js CLOSED TREE
Pushed by malexandru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f72073d5c502
Prevent Remote Settings server URL to be modified in release r=Gijs

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

Status: REOPENED → RESOLVED
Closed: 3 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 73
Flags: needinfo?(mathieu)

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.

Flags: needinfo?(mathieu)

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...

Flags: needinfo?(mathieu)

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.

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.

You need to log in before you can comment on or make changes to this bug.