1547991 - [meta] Implement security features for local profile data

Status: RESOLVED FIXED

(Firefox :: Remote Settings Client, enhancement)

Description

[Mathieu Leplatre [:leplatrem]]

Currently, an attacker that gains access to the user profile (eg. preferences, indexeddb) could alter the local data of Remote Settings.

Indeed, the signature verification only happens during synchronization.
Plus, a preference can be flipped to disable the signature verification.

This can be problematic for use-cases like blocklists (eg. https://bugzilla.mozilla.org/show_bug.cgi?id=1532170).

For Normandy, we added another level of security, which makes sure that the records we take into account were genuinely published by us (https://bugzilla.mozilla.org/show_bug.cgi?id=1538248), but we don't handle the case where a record would have been removed from the list.

Let's use this ticket to track any security improvement with regards to local data authenticity.

Comment 1

[:Gijs (he/him)]

Is protecting against removal really worthwhile? Presumably if I am an attacker with local write access to the profile I can just delete all the files, or replace them with older copies that don't yet have the data that I want them not to have.

Comment 2

[Mike de Boer [:mikedeboer]]

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

Is protecting against removal really worthwhile? Presumably if I am an attacker with local write access to the profile I can just delete all the files, or replace them with older copies that don't yet have the data that I want them not to have.

This is part of the process to move our search configurations over to Remote Settings completely. We are trying to put minimal hijacking remediation in place to at least the level of the Search Service since part of the cached configuration is now going to live in Remote Settings' SQLite DB.

Comment 3

[:Gijs (he/him)]

(In reply to Mike de Boer [:mikedeboer] from comment #2)

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

Is protecting against removal really worthwhile? Presumably if I am an attacker with local write access to the profile I can just delete all the files, or replace them with older copies that don't yet have the data that I want them not to have.

This is part of the process to move our search configurations over to Remote Settings completely. We are trying to put minimal hijacking remediation in place to at least the level of the Search Service since part of the cached configuration is now going to live in Remote Settings' SQLite DB.

How does removing items from the list end up being search hijacking? Isn't the "whole point" of search hijacking inserting another item that isn't of the user's choosing?

Comment 4

[Mike de Boer [:mikedeboer]]

Indeed, but Mathieu is talking about 'alter the local data', not just removing in comment 0.

Comment 5

[:Gijs (he/him)]

(In reply to Mike de Boer [:mikedeboer] from comment #4)

Indeed, but Mathieu is talking about 'alter the local data', not just removing in comment 0.

... and I was specifically responding to this paragraph, because I'd recently reviewed the relevant patches:

(In reply to Mathieu Leplatre [:leplatrem] from comment #0)

For Normandy, we added another level of security, which makes sure that the records we take into account were genuinely published by us (https://bugzilla.mozilla.org/show_bug.cgi?id=1538248), but we don't handle the case where a record would have been removed from the list.

Comment 6

[Mike de Boer [:mikedeboer]]

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

(In reply to Mike de Boer [:mikedeboer] from comment #4)

Indeed, but Mathieu is talking about 'alter the local data', not just removing in comment 0.

... and I was specifically responding to this paragraph, because I'd recently reviewed the relevant patches:

(In reply to Mathieu Leplatre [:leplatrem] from comment #0)

For Normandy, we added another level of security, which makes sure that the records we take into account were genuinely published by us (https://bugzilla.mozilla.org/show_bug.cgi?id=1538248), but we don't handle the case where a record would have been removed from the list.

OK, this I don't know. Even though I do think it's a nice-to-have.

Comment 7

[Mathieu Leplatre [:leplatrem]]

How does removing items from the list end up being search hijacking?

Protection against removal makes sense for blocklists :) I was thinking of Bug 1532170, where an obvious hijack could consist in removing the rule that prevents a specific search engine to be enabled.

Normandy, we added another level of security, which makes sure that the records we take into account were genuinely published by us (https://bugzilla.mozilla.org/show_bug.cgi?id=1538248), but we don't handle the case where a record would have been removed from the list.

OK, this I don't know. Even though I do think it's a nice-to-have.

This makes sense when the publication of records is automated (eg. server to server). In most use-cases we have multi sign off, where a human reviews and approves the changes to be published.

In the case of Normandy, I can't think of a situation where removing a recipe from the local DB could be harmful.

Comment 8

[Mathieu Leplatre [:leplatrem]]

The first round of improvements were shipped. I'm closing this bug. We can reopen a new one if some additional ideas come up.