Security/Reviews/Mobile/AndroidSync

Date: 2011.11.18

Items to be reviewed

• https://wiki.mozilla.org/Services/AndroidSyncFP

see also
https://wiki.mozilla.org/Privacy/Reviews/AndroidSystemStorage
https://wiki.mozilla.org/Services/AndroidPasswordStorageFP
https://wiki.mozilla.org/Security/Reviews/Mobile/AndroidSystemStorage
https://wiki.mozilla.org/Services/NativeSync/Bookmarks_and_History

Code

• https://github.com/mozilla-services/android-sync
• https://github.com/mozilla-services/SetupSync

(See branches.)

Introduce Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

Implement the same level of data syncing for Native Fennec as we provide for XUL Fennec. That's it in a nutshell. We're also intending to follow Android conventions in doing so: e.g., to provide your Sync account through the usual Android account panel, respecting background sync settings (e.g., roaming), etc. etc. … not that we really have a great deal of choice in the matter! Aiming to ship in January

What solutions/approaches were considered other than the proposed solution?

The only alternative is to have the Fennec application itself do syncing. We know from experience that this isn't as good a user experience, and would be a superset of the engineering required to do it this way.

Why was this solution chosen?

It's pretty much the only feasible approach. Also lets users use Sync without not necessarily using Fennec

Any security threats already considered in the design and why?=

Yes. In order to provide data to Native Fennec, we need to write into the Android bookmarks/history store. Other applications have access to that (and in ICS it will very likely sync with desktop Chrome), so there's a possibility (near certainty?) of user data leakage or injection. The backend is not changing at all. Re password storage: that's a bigger project now - at the moment the proposal for password storage is to have a password storage content provider that Fennec will talk to (and Sync may talk to) - passwords are not stored in the system storage, but in Fennec in the profile Credentials for Sync need to be stored in the Android account manager. This already holds e.g., your email credentials.

• This is not the system store though right? No other application has access to these credentials. - based on app signing key and app id - planning on cross signing to take advantage of this (Fennec, Sync, Sync setup - 3 apps)

Uses platform crypto libs for the most part

Threat Brainstorming

• (decoder's questions)
  • How is the data stored on the device such that Fennec can access it?
    • Can other applications read that data?
      • If so, how is confidential information protected?
    • Can other applications write that data?
      • If so, what prevents an attacking application to modify the data to bypass the Android security model? Examples:
        • Modify data such that malicious javascript is injected into content (same impact as XSS/CSRF, data theft)
        • Modify data such that malicious javascript runs at chrome level (bypasses the protection provided by user separation, attacker can access all browser data on device)
      • Yes. So we should revisit how we sanitize the data that we receive from the various clients?
      • We know that other clients (360 browser) are already writing this database. Should we consider restricting the capabilities of records we get from sync, e.g. no bookmarklets?
• Application permissions - credential system storage, internet, write to browser storage - setup and client are bundled so they have one shared set of permissions
• Password storage content provider: How can an application talk to it and how does the validation happen that this application is allowed to do that (authentication) ?
• is the application written in a way where it could easily switch to using a different store, for example if an option is added to Fennec to use a private db ?
  • This option doesn't currenlty exist, however in the future an option could be added so that Fennec could direclty use our database for bookmarks/history rather than the stock browser's data store
• other applications (browsers) can write data that gets synced via the Mozilla Sync service - so the threat of malicious data being injected into the android system store this way already exists (there is no new threat with other apps writing into browser store)
  • As discussed, this is right now only the case for applications that we're explicitely allowed to sync, on Android, all applications with system store access will be able to inject data => different threat model.
• potential to inject/modify bookmarks, and include schemes that are dangerous on desktop Firefox (ones that launch external apps, or protocols added by add-ons). Worth filtering?

Conclusions / Action Items

• [imelven] check out limits around android storage blob sizes (potential DoS)
• [Sync Team] Document which parts of the data are stored in which locations (system store vs. account manager) and who can access it?
• [secteam] do some testing/investigation when apk is available (on sync client and all of our applications that might receive data from the system store, e.g. Fennec/Firefox)
  • Specifically, how all sorts of malicious data from system store is handled by Fennec/Firefox