1237893 - Allow SwitchBoard to remotely manage Shared and Gecko preferences

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

We use Android Shared and Gecko preferences to control various capabilities in Firefox for Android. We should create a configuration system in SwitchBoard to allow the client to override preferences remotely. For Gecko prefs, we'd treat these as local "default overrides" much like Distributions currently set preferences.

This would allow us to quickly tune or disable features without needing a new release.

Comment 1

[Richard Newman [:rnewman]]

Sec review needed, I suspect. Or whitelist prefs.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #1)
> Sec review needed, I suspect. Or whitelist prefs.

Can you explain more about why this would need a sec review if the other aspects of using SwitchBoard to enable/disable features does not?

Also, I do not want a whitelist at all. That would defeat the intent of never needing to ship changes.

Comment 3

[Richard Newman [:rnewman]]

Yeah, I understand the value.

The concern is this: if compromising Switchboard allows you to remotely flip prefs — both Android and Gecko — on a device without prompting, the attacker can do fun stuff like:

* Change updater locations for Gecko-driven updates like add-ons and GMP.
* Alter the Java-side updater endpoint? (Probably not a concern thanks to signing, but still...)
* Alter the user's FxA/Sync endpoints.
* Fetch snippets from a different place.
* Load arbitrary URLs via tab queues?
* Install add-ons? Not sure how easy it is to attack AddonManager if you have write access to prefs.
* Disable Master Password.
* Turn on or off features like tracking protection, safe browsing, etc.

and stuff we haven't thought of, including exploiting vulnerabilities in SharedPreferences or the Gecko prefs system or the Android filesystem.

Probably we haven't hardened everything that consumes prefs, particularly SharedPreferences, against untrusted input.


By adding this feature we'd be taking SwitchBoard from a relatively benign service that hands out yes/no answers into one that has write access to core browser configuration, and would need to be appropriately protected: it would be a central point of remote control. Services like Balrog and AMO are protected by signing keys; I doubt that SwitchBoard's data is.

On devices with MITM certs, this would also allow the network owner to arbitrarily flip prefs by intercepting requests.


I think whitelisting is a reasonable middle-ground: if you want to be able to remotely toggle a feature, check that the prefs that control it are safe, and add them to the list. (And don't store that list in prefs! :D)

I'm open to other solutions, too, but it seems hasty to ignore this dramatic a shift in capabilities.

Comment 4

[:Margaret Leibovic]

I think we should start with trying to use Switchboard to control a single pref before coming up with a generic solution.

File separate bugs for any suggestions about specific features.

Comment 5

[:Margaret Leibovic]

I implemented a pattern for gecko prefs for my patch in bug 1241566.

Let's not create a generic way to change any pref. Too many risks. If we have a pref in mind we expect we'll need to flip in a rollback, let's land logic for that in the product.