View source for Reviews/B2G/AppUpdates

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

<b>Open Questions</b><br>
* What does the UI look like for app updates? Is it the same as for system updates (ie via the notification tray?) I see https://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js but is this used for app updates or just system updates?
* Where do packaged app updates come from (ie where are they hosted, marketplace?) Is this still an open question?
* How does the update process work with signing (probably need to combine signing review with this review)?

==Architecture==
The following components play a role in app updates:
*Gaia System App
**[http://mxr.mozilla.org/gaia/source/apps/system/js/update_manager.js 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
**[http://mxr.mozilla.org/gaia/source/apps/system/js/updatable.js 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
**[http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm 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
**[http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.js]: 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 [http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/apps/nsIDOMApplicationRegistry.idl mozIDOMApplication] object, which has a [http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.js#396 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:

# Check each app to see if there is an available update
# If there is an update for an app, the process depends on whether the app is packaged/hosted or removable/non removable:

*Non-removable Packaged Apps (http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1225)
*# No updated as part of webapps process - these are updated with a system update process

*Non-removable Hosted Apps (http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1230 onwards)
*# Just check if new app cache manifest is available
*# If so, do async download of manifest contents

*Removable Packaged Apps (http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1122)
*# Send a 'Webapps:CheckForUpdate:Return:OK' event (from webapps.jsm)
*# Set properties of the update on the app object, then fire a downloadavailable event
*# Event caught in system app (updatable.js) which adds itself updates queue in update manager (UpdateManager.js)

*Removable Hosted Apps (http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1149)
*# Update web apps registration (system messages & web activities)
*#  Store the new manifest
*# Update the webapps registry
*# If not updatable then send Webapps:CheckForUpdate:Return:OK message to fire a downloadapplied event
*# Else, Start app cache update (nsOfflineCacheUpdateService::CheckForUpdate)
*# Observer for this update sends Webapps:CheckForUpdate:Return:OK, when check has been done.
*# 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.

# Handle the user click, calling startDownloads [http://mxr.mozilla.org/gaia/source/apps/system/js/update_manager.js#83]
# Call updatable.download [http://mxr.mozilla.org/gaia/source/apps/system/js/update_manager.js#103]
# Calls download on the app object itself [http://mxr.mozilla.org/gaia/source/apps/system/js/updatable.js#32]
# Enter app.download function, which just sends message to WebApps.jsm [http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.js#386]
# WebApps.jsm catches the message and calls startDownload(manifestURL) [http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#915]
# WebApps,jsm loads the app object for that Manifest, does some checks, then: 

* if Hosted app, then
*# Check if it has an appcache manifest, and if so then update the cache by calling startOfflineCacheDownload (http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#946)

* else, for packaged apps, then 
*# Download the updateDated manifest, then if that is valid then
*# Download App update (zip file)  http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#970

   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 [http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1718 Webapps.jsm#1718].

==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?
*** Other possible DoS scenarios? Version number corruption?

* 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 checkForUpdate, so an app could trigger an update for another app. But the [http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1106 update code] retrieves the app to update based on the manifest, and so while a compromised process could trigger updates for other apps, it can't provide any malicious parameters to that update. See bug 820206 for more info on attacks related to spoofing webapps:* system messages. But I dont think there is an issue here.

* Partial update makes app unusable
** Can an app be half updated? (appcache yes? packaged no?)

* App update is incompatible with the underlying gecko version?
** how do we address this? (not really a security issue though)

* 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==

* SecReview Bug https://bugzilla.mozilla.org/show_bug.cgi?id=804049

[[Category:SecReview]]