Description: If user opens Rocketbar and types in "app:" they are taken to "app:search.gaiamobile.org/index.html" a non-functional page that appears to be a second instance of the Rocketbar. If user then pulls down Rocketbar in this new window and changes the address to read "app:browser.gaiamobile.org/index.html" they are able to access the old version of the browser app. Additionally, it appears that this method can be used to open any application on the phone from Gallery and Cost Control, to the Settings app (which features options not normally available to user like "SIM Toolkit".) If the user changes the URL to leave out "/index.html" they are given access to a view of all folders and files within the app. Repro Steps: 1) Updated Buri to BuildID: 20140203040201 2) Tap Rocketbar from Homescreen 3) Type "app:" 4) Drag Rocketbar down from status bar 5) Edit existing text in Rocketbar to app:browser.gaiamobile.org/index.html Actual: User is given what might be described access within the Rocketbar to areas not normally avalaible Expected: Rocketbar search does not give unexpected access to apps Environmental Variables: Device: Buri v1.4 Master Mozilla RIL BuildID: 20140203040201 Gaia: 3b2fe2f86164f95db699b6ea2661925b21ecb994 Gecko: 44ba69cacd7e Version: 29.0a1 Firmware Version: Notes: Repro frequency: 3/3, 100% See attached: screenshots Note: May be related to bug 963372

I'm unsure if this has security implications. Paul - What do you think?

(In reply to Jason Smith [:jsmith] from comment #3) > I'm unsure if this has security implications. > > Paul - What do you think? Talked with Gregor in person about this - he thinks this isn't going to have security impact, as the file view of packaged apps that is possible to access here is read only.

Comment on attachment 8369912 [details] Github pull request Clearing review for now. As discussed, we probably can't just whitelist HTTP and HTTPS and if you can access app URLs in the Rocketbar then you can do the same from an iframe in any third party app. If this is a problem then it may need to be fixed at the platform level.

Comment on attachment 8369912 [details] Github pull request Fixing this would involve fixing the app:// protocol handler in the platform.

It's read-only so no real security concern here. If we want to fix this, we should fix the protocol handler. Unblocking the rocketbar-mvp bug for now.

I can't reproduce this on 2.0/2.1 Can you Brogan?

I am not able to reproduce this on Flame 2.1, Flame 2.0, Buri 2.1, or Buri 2.0 Environmental Variables: Device: Flame Master Build ID: 20140716040207 Gaia: d29773d2a011825fd77d1c0915a96eb0911417b6 Gecko: 691ffea49efb Version: 33.0a1 (Master) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Environmental Variables: Device: Flame 2.0 BuildID: 20140716000201 Gaia: 5f8b1b8a2da9e3b531eee817a669f57fa4d9b9c6 Gecko: 913827496f65 Version: 32.0a2 (2.0) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Environmental Variables: Device: Buri Master Build ID: 20140716040207 Gaia: d29773d2a011825fd77d1c0915a96eb0911417b6 Gecko: 691ffea49efb Version: 33.0a1 (Master) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Environmental Variables: Device: Buri 2.0 Build ID: 20140716000201 Gaia: 5f8b1b8a2da9e3b531eee817a669f57fa4d9b9c6 Gecko: 913827496f65 Version: 32.0a2 (2.0) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Actual Results: Search results for "app:" are displayed, no second instance of Rocketbar is opened

I'm not sure if I see this for 1.4 either. Closing as WFM.