In bug 772404 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. Initial information: https://wiki.mozilla.org/Gaia/System/Apps#Updates (outdated I think) Relevant bugs: bug 790558 bug 796045 Code: 'checkforUpdate' in http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.js

How are things going with this, Paul?

Do we have an update story yet for apps finalised yet? I thought this was pending signed apps?

Ok I see signed apps is resolved. Trying to untangle the mess of bugs here and piece together the state of things. Jsmith, from bug 823189 you sound like you are across the general process - are you able to point me to anything that might help me understand the current update process, and/or the people to talk to get this information?

Nevermind, I think I have found the relevant code, and can work from there: http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1101 We do also need to look at app signing too, maybe in conjunction with this.

bsmith is a good person to check on any the signing checks. As for updates, I think Fabrice implemented the large majority of the gecko portion of the API. I'd recommend talking to bsmith and fabrice.

Slightly broadening the scope of this review now that I am familiar with the code. Basically I am covering all app update flows in this review, with the exception of those performed as part of the system update, which have been covered in https://wiki.mozilla.org/Security/Reviews/B2GUpdates. Working on a draft here: https://wiki.mozilla.org/Reviews/B2G/AppUpdates Review/Comment/Contributions appreciated.

An internal (secteam) review was conducted last week. Actions from this are: 1. test for normal app updates to see if initiated by user or not (notifications displyed, test this?) 2. Check to make sure people dont appcache their update manifest (appstore-side) 3. Are we relying on the app to update itself, need to check update cadence in review process (appstore-side) 4. Check when delete old app happens (as part of applying packaged update) Im not raising these as dependent bugs, as they are really just questions, and I will take these to the formal review when this occurs. Just a note on 3 - from another thread on dev-b2g, I believe the update cadence is daily, but at a random time daily. Still need to confirm the exact mechanism.

(In reply to Paul Theriault [:pauljt] from comment #7) > An internal (secteam) review was conducted last week. Actions from this are: > > 1. test for normal app updates to see if initiated by user or not > (notifications displyed, test this?) The user can initiate update checks in B2G by going to settings->DeviceInformation->CheckNow I'm not sure if that answers the question > 2. Check to make sure people dont appcache their update manifest > (appstore-side) It's quite possible that if the marketplace app put the update manifest into an appcache that we'd be in trouble. But the app lives in a different data-jar, so no matter what it appcaches we ignore that when checking the update manifest for the app. > 3. Are we relying on the app to update itself, need to check update cadence > in review process (appstore-side) Every 24 hours we check apps for updates. If the phone is off at that time, we'll check as soon as we get data connection.

(In reply to Jonas Sicking (:sicking) from comment #8) > (In reply to Paul Theriault [:pauljt] from comment #7) > > An internal (secteam) review was conducted last week. Actions from this are: > > > > 1. test for normal app updates to see if initiated by user or not > > (notifications displyed, test this?) > > The user can initiate update checks in B2G by going to > settings->DeviceInformation->CheckNow > > I'm not sure if that answers the question Sorry the question was worded better on https://wiki.mozilla.org/Reviews/B2G/AppUpdates: I wanted to understand if, once the device discovered an app update is available, what the UI looked like. Is it similar to the System update notification? Or is it just applied without asking the user? Is the behavior different between hosted/packaged apps? Does the user choose to apply or not? Is there some record or last time an app was updated? (I can probably find the answers to many of these questions myself, but just writing down the question more clearly.) > > > 2. Check to make sure people dont appcache their update manifest > > (appstore-side) > > It's quite possible that if the marketplace app put the update manifest into > an appcache that we'd be in trouble. > > But the app lives in a different data-jar, so no matter what it appcaches we > ignore that when checking the update manifest for the app. So appcache storage is seperated by data-jar origins similar to indexeddb and cookies? I didnt know that, thanks. > > > 3. Are we relying on the app to update itself, need to check update cadence > > in review process (appstore-side) > > Every 24 hours we check apps for updates. If the phone is off at that time, > we'll check as soon as we get data connection. Ok thanks.

Might be worthwhile to stick a bunch of us in a room to finish off the questions you have and get bugs filed for any issues that need to be immediately addressed. We are running low on time for v1, so if anything is stop ship, we'll want to know it asap. I'd pull in people such as: - Julien (Gaia) - Etienne (Gaia) - Fabrice (Platform) - Me (QA) - Jonas (Architect) - Lucas (Security)

Yes, definitely, I was hoping for a proper secreview meeting this week, but I understand everyone is away until Tuesday in the US? I am just testing/reviewing some more stuff at the moment, but I will send out an email to these people shortly to try to figure out a secreview time for this week.

> > I wanted to understand if, once the device discovered an app update is > available, what the UI looked like. Is it similar to the System update > notification? Or is it just applied without asking the user? Is the behavior > different between hosted/packaged apps? Does the user choose to apply or > not? Is there some record or last time an app was updated? This should be the same UI for system updates, packaged apps, hosted+appcache apps or (I'm not sure) hosted apps. For 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). For app updates, the update is applied as soon as it is downloaded, unless the app is running in front. If it is the case, we wait that it is hidden (most probably the user will press "home") to apply the update.

(In reply to Julien Wajsberg [:julienw] from comment #12) > > > > I wanted to understand if, once the device discovered an app update is > > available, what the UI looked like. Is it similar to the System update > > notification? Or is it just applied without asking the user? Is the behavior > > different between hosted/packaged apps? Does the user choose to apply or > > not? Is there some record or last time an app was updated? > > This should be the same UI for system updates, packaged apps, > hosted+appcache apps or (I'm not sure) hosted apps. > > For 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). > > For app updates, the update is applied as soon as it is downloaded, unless > the app is running in front. If it is the case, we wait that it is hidden > (most probably the user will press "home") to apply the update. Thanks Julien, that answers my question.

> > > 2. Check to make sure people dont appcache their update manifest > > (appstore-side) > > It's quite possible that if the marketplace app put the update manifest into > an appcache that we'd be in trouble. > > But the app lives in a different data-jar, so no matter what it appcaches we > ignore that when checking the update manifest for the app. Jonas, just to make sure I understand you correctly: Consider an active MITM attack scenario against a hosted app that doesn't use SSL: 1. FooApp (a hosted app, not SSL) requests any content over content over http. 2. Attacker responds modifies response to include script to trigger a check for update 3. The WebApps service (in the system app process, but privileged?) makes a request to FooApp's web server to check the app manifest for a new version. 4. The attacker then modifies the contents of the app manifest to include a reference to a spurious appcache manifest 5. The attacker deliberately attempts to cache the app manifest by including it in the list of files cached by the appcache manifest. If I understand you (&the code) correctly this is not a threat, as step 5 doesn't work as the attacker would like, due to data-jars. Ignoring that apps are not updated while open, even if this sequence of events happens, the appcache is only poisoned in the data-jar belonging to the app. The code responsible for this is http://mxr.mozilla.org/mozilla-central/source/uriloader/prefetch/nsOfflineCacheUpdate.cpp#1368, noting the call to nsApplicationCacheService::BuildGroupIDForApp.

Paul, I'm quite sure that we can't cache the app manifest this way. The app manifest is kept in the Application Registry ([1]) and that's all. However, even if this could happen, I don't understand what would be the final goal for the attacker ? [1] http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1844

I was thinking along the lines of either application DoS (e.g. permanent defacement) or perhaps permanent app compromise (e.g. run script provided by attacker, every time the user runs the app) What I was thinking was that if the manifest was cached, then the request which retrieves the update as part of the update check would get the cached version. But I dont know what happens if you use XHR to request an appcached page (i.e. here http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1395)

Oh derp. At a guess the very next line probably answers my question :| 1396 xhr.channel.loadFlags |= Ci.nsIRequest.INHIBIT_CACHING;

(In reply to Paul Theriault [:pauljt] from comment #17) > Oh derp. At a guess the very next line probably answers my question :| > > 1396 xhr.channel.loadFlags |= Ci.nsIRequest.INHIBIT_CACHING; And this xhr really lives in gecko, not in the App.. so I doubt the App's AppCache has any control on this.

Review was conducted earlier in the week. Two action items came out of the review: ** Add UI the show source of the app - there is a bug for this already (bug 827562) ** Storage permission could be granted by MITM to a hosted app not using SSL since it is allowed for hosted apps. This permissions grants unlimited storage, so the MITM could then try to fill up the disk. I'll raise a separate bug to discuss solutions to this further.

(In reply to Paul Theriault [:pauljt] from comment #19) > Review was conducted earlier in the week. > > Two action items came out of the review: > ** Add UI the show source of the app - there is a bug for this already (bug > 827562) I should note that bug targets the install prompt. We'll probably want to file an additional one for the settings apps perm UI as well.

marking this resolved fixed as the review happened It does appear the following is follow-up * Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug) Confirm the update UI for pure hosted apps (ie no appcacheache) --> [jsmith] Just tested, no UI shown, update is automatically applied Storage permission could be granted by MITM to a hosted app not using SSL. This grants unlimited storage, so the MITM could then try to fill up the disk. Add UI the source of the app (install and app info section, under permission) --> install prompt bug might be https://bugzilla.mozilla.org/show_bug.cgi?id=827562