Reviews/B2G/AppUpdates

From MozillaWiki
Jump to: navigation, search

App Updates Security Review

Overview

In bug 772404 (https://wiki.mozilla.org/Security/Reviews/B2GUpdates) we have looked at gecko and gaia updates. We also need to review the update process for third party apps, which is the purpose of this bug.

Architecture

The following components play a role in app updates:

  • Gaia System App
    • update_manager.js: This code is responsible for starting the process of checking for updates, manages queues of updates and downloads, and provides UI via notifications to alert the user of the various stages of the updates
    • updatable.js: This code represents an update - either an app or system update. It has methods like download() and applyUpdate() and provides an object to register callbacks for progress updates.
  • Gecko
    • Webapps.jsm: WebApps registry service handles the actual downloads of manifest at the request of the Gaia system app, passing the results back to the system app via WebApps.js
    • [1]: This is the child process half of the webapps service, which talks to the parent via system messages. The system app (update_manager.js) calls methods on app objects which are defined by this file.


Data Flow Enumeration

Inside Gecko, Apps are represented by a mozIDOMApplication object, which has a checkForUpdate() function. Apps can request to check for an update to themselves, or the system app also checks for app updates as part of a global update check (by setting the gaia.system.checkForUpdates setting to true, which is picked up by update_manager.js)

Check for App Update

Either way, the process to check for an update to an individual app is as follows:

  1. Check each app to see if there is an available update
  2. If there is an update for an app, the process depends on whether the app is packaged/hosted or removable/non removable:
  • Removable Hosted Apps (http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1149)
    1. Update web apps registration (system messages & web activities)
    2. Store the new manifest
    3. Update the webapps registry
    4. If not updatable then send Webapps:CheckForUpdate:Return:OK message to fire a downloadapplied event
    5. Else, Start app cache update (nsOfflineCacheUpdateService::CheckForUpdate)
    6. Observer for this update sends Webapps:CheckForUpdate:Return:OK, when check has been done.
    7. downloadapplied/downloadavailable event caught in system app (updatable.js) which adds itself updates queue in update manager (UpdateManager.js)

Download App Update

The update Manager fires a notification which has a download button on it. When clicked, the download process is started downloading all the queued updates.

  1. Handle the user click, calling startDownloads [2]
  2. Call updatable.download [3]
  3. Calls download on the app object itself [4]
  4. Enter app.download function, which just sends message to WebApps.jsm [5]
  5. WebApps.jsm catches the message and calls startDownload(manifestURL) [6]
  6. WebApps,jsm loads the app object for that Manifest, does some checks, then: 
  1719     // Here are the steps when installing a package:
  1720     // - create a temp directory where to store the app.
  1721     // - download the zip in this directory.
  1722     // - check the signature on the zip.
  1723     // - extract the manifest from the zip and check it.
  1724     // - ask confirmation to the user.
  1725     // - add the new app to the registry. 1726     // If we fail at any step, we backout the previous ones and return an error.

For further on these steps see Webapps.jsm#1718.

Applying App Updates

For app updates, the update is applied as soon as it is downloaded, unless the app is running in foreground. If that is the case, we wait that it is hidden (most probably the user will press "home") to apply the update.

Note that this differs from the system updates, we have an additional prompt when it is downloaded, to let the user choose to apply it now (the phone will reboot) or later (when the phone is rebooted next time). Also note that Gaia apps, are only updated during the system update.


Threat Analysis

  • App isn't updated in a timely manner
    • what could cause the initial update check to fail?
      • What about if the update manifest is accidentally included in an appcache? Not an issue, since Gecko does the retrieval of the manifest, so appcache doesn't apply.
      • Are there Other possible DoS scenarios? Version number corruption? Apps are updated if the previous manifest hash doesn't match the one which is retrived as part of the update check. So no issue.
  • Unsigned update gets applied?
    • app updates are signed for packaged apps. Hosted apps are not installed, and are at risk, but same model as the web. (i.e. use SSL to protect content integrity)
  • Wrong app gets updated?
    • "Currently a compromised process could spoof the input parameter to Webapps:CheckForUpdate message. See here. However the supplied appid (oid) paramemeter doesn't appear to be used in the parent (webapps.jsm) . So an app could trigger an update for another app, but not cause a mismatch.
  • Partial update makes app unusable
    • Can an app be half updated?
      • Hosted App with Appcache?
      • Packaged apps: what happens in case of running out of diskspace which applying an update?
  • Signed update gets applied to the wrong app?
    • Can this happen? Are signatures per domain/manifest/what? IE could one signed appupdate be somehow applied over another app somehow?
  • An old update get applied (perhaps introducing a security vulnerability)

Links

Retrieved from "https://wiki.mozilla.org/index.php?title=Reviews/B2G/AppUpdates&oldid=505254"