Reviews/B2G/AppUpdates: Difference between revisions

Reviews/B2G/AppUpdates (view source)

Revision as of 11:32, 8 January 2013

386 bytes added , 8 January 2013

→‎App Updates Security Review

Ptheriault

canmove, Confirmed users

1,220

edits

@@ Line 3: / Line 3: @@
 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==
@@ Line 13: / Line 17: @@
 **[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.
-<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 not sure if this is only for system updates or for all updates.
 ==Data Flow Enumeration==
@@ Line 76: / Line 79: @@
 * App isn't updated in a timely manner
 ** what could cause the initial update check to fail?
-*** network DoS? Out of scope surely
 *** What about if the update manifest is accidentally included in an appcache?
+*** Other possible DoS scenarios? Version number corruption?
-* App update integrity compromised
+* 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)
-**Can one app's update be applied over a different application? Normal flow prevents this since the child process tells the parent what manifest to update, but the parent then retrieve the associated app. Child process could be compromised, and send a spurious manifest, however
 * 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.
+** 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==