744928 - Windows 8 Metro Firefox Sec Review

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance: Review Request, task, P4)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Who is/are the point of contact(s) for this review?
    
Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):
    
Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:
    
Does this request block another bug? If so, please indicate the bug number This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?

Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.)

Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?

Are there any portions of the project that interact with 3rd party services?

Will your application/service collect user data? If so, please describe 

If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size):

Desired Date of review (if known from https://mail.mozilla.com/home/[e-mail]/Security%20Review.html) and whom to invite.

Comment 1

[Jim Mathies [:jimm]]

(In reply to Curtis Koenig [:curtisk] from comment #0)
> Who is/are the point of contact(s) for this review?

I suppose I can be. Others on the immediate platform team include Brian Bondy, Rob Strong, and Tim Abraldes. Mark Finkle is heading up the front end.

> Please provide a short description of the feature / application (e.g.
> problem solved, use cases, etc.):

A new browser for the immersive environment in Windows 8. Both desktop and metro browser operate out of the same install and leverage the same runtime. However the metro browser will use a different front end and widget layer along with modest changes in places like toolkit.

http://mxr.mozilla.org/projects-central/source/elm/browser/metro/
http://mxr.mozilla.org/projects-central/source/elm/widget/windows/winrt/

> Please provide links to additional information (e.g. feature page, wiki) if
> available and not yet included in feature description:

https://wiki.mozilla.org/Firefox/Windows_8_Integration

> Does this feature or code change affect Firefox, Thunderbird or any product
> or service the Mozilla ships to end users?

Yes

> Are there any portions of the project that interact with 3rd party services?

No

> Desired Date of review (if known from
> https://mail.mozilla.com/home/[e-mail]/Security%20Review.html)
> and whom to invite.

*shrug*

We won't fully merge with mc until q4. Tentative plan is to integrate and start shipping with nightly builds by the end of the year. This schedule may slip.

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Risk/Priority Ranking Exercise https://wiki.mozilla.org/Security/RiskRatings

Priority: 2 (P4) - Team Quarterly Goal

Operational: 0 - N/A
User: 0 - N/A
Privacy: 0 - N/A
Engineering: 1 - Minor
Reputational: 5 - Blocker

Priority Score: 24

Comment 3

[Jim Mathies [:jimm]]

We are getting closer to the point where we will be enabling the metro browser on mc. ETA maybe around the first or second week of January. Should we get this kicked off before then?

Comment 4

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to Jim Mathies [:jimm] from comment #3)
> We are getting closer to the point where we will be enabling the metro
> browser on mc. ETA maybe around the first or second week of January. Should
> we get this kicked off before then?

that would be a good idea, is there a date on the schedule that works for you all?
https://mail.mozilla.com/home/[e-mail]/Security%20Review.html

Comment 5

[Jim Mathies [:jimm]]

(In reply to Curtis Koenig [:curtisk] from comment #4)
> (In reply to Jim Mathies [:jimm] from comment #3)
> > We are getting closer to the point where we will be enabling the metro
> > browser on mc. ETA maybe around the first or second week of January. Should
> > we get this kicked off before then?
> 
> that would be a good idea, is there a date on the schedule that works for
> you all?
> https://mail.mozilla.com/home/[e-mail]/Security%20Review.html

The Jan. 3rd date works for us. People who should be invited are:

myself (Jim Mathies)
Brian Bondy
Rob Strong (opt)
Mark Finkle (opt)

One major component to go over would probably be the new os integration piece - 

http://mxr.mozilla.org/projects-central/source/elm/browser/metro/shell/commandexecutehandler/

Note our schedule has us landing all of the remaining code currently unique to elm on mc over the next few weeks. But to turn all this on in nightly builds we need to add a config option. So the code will be on mc but won't be enabled. Bug 813488 is the final bit in that process, which this bug blocks.

Comment 6

[Jim Mathies [:jimm]]

Also the nsBrowserApp bits in bug 771271 and bug 762344.

Bug 747347 is the main merge bug.

All metro work currently resides under the product "Metro Firefox".

Comment 7

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Scheduled: https://mail.mozilla.com/home/[e-mail]/Security%20Review.html?view=month&date=20130110&action=view&invId=250711-250710&pstat=AC&exInvId=250711-253802&useInstance=1&instStartTime=1357236000000&instDuration=3600000

Comment 8

[Brian R. Bondy [:bbondy]]

Updates in Metro
================

I'm not sure if you want to have a separate security meeting about this, but one of the topics I'd like to discuss at the Metro security meeting is how updates will work in the Metro environment.
 
At the moment updates only happen from the Desktop browser, but we are working on a task now to enable updates on the Metro browser as well.
The reason we want to do this is because if a user only uses the Metro browser and not the Desktop browser, they wouldn't get updates otherwise.

We have some security concerns with the initial plan, and we'd like feedback, ideas, and clarification about what things are absolutely needed if any to land on m-c, and ditto aurora.


-----
The normal update process in use today:
-----
1. On application startup, if an update is staged, finish the update, after the update restart the browser.
2. If no update is staged from startup, updates are downloaded on demand from the about box, or from an update wizard (if there were previous errors), or after a given period of time controlled by a preference.
3. After updates are downloaded, they are applied (if background updates are enabled).  If no UI is present, the next time the browser is restarted the update will be completed.  If a UI is present the user is prompted to restart the browser.


-----
Background information about the Metro browser:
-----
- The same installation, and even the same firefox.exe is used for both the Metro browser and the Desktop browser
- Each browser has a different profile
- Some config may be synced by Firefox Sync between both browsers


-----
The proposed changes to introduce a Metro update:
-----
0. We cannot simply allow either browser to download and install updates independently because that would sometimes lead to in-use errors and also sometimes the same update would be attempted to be installed twice.  Although there is no in-use error from Windows when the Metro browser is started.
1. Enable updates on the Metro side via prefs in each profile. Both Desktop and Metro side will now be able to download updates and apply them.
2. For the Desktop side, on application startup, if an update is staged, finish the update, after the update restart the browser. If an update is not staged then create a synchronyzation object with the name "DesktopFirefoxStarted-{HashOfInsatllPath}".
3. For the Metro side, on application startup, check if "Firefox-{HashOfInsatllPath}" exists.  If it does just start the browser as normal.  If not, then if an update is staged, finish the update, after the update restart the Metro browser.
4. When downloading an update, before downloading it, try to create a global synchronization object named "FirefoxDownloading-{HashOfInsatllPath}".  If it already exists, do not perform the download.  If it does not exist, then do the download as before.
5. On the Metro side, if "DesktopFirefoxStarted-{HashOfInsatllPath}" exists, apply the update if background updates are enabled.  The update will be completed on the next browser start, refer to #2 and #3 in this paragraph.
6. On the Desktop side, apply the update.  If no UI is present, the next time the browser is restarted the update will be completed.  If a UI is present the user is prompted to restart the browser.

----
Concerns we have with the proposed solution that we're not sure if security will be OK with:
-----
- Since the Metro side has no update-UI,  a user could leave the Metro browser open for a long time, and never use the Desktop browser, and if there is a 0-day attack they wouldn't get notifications that critical updates are needed. 
- A malicious application could create the download mutex (Firefox-{HashOfInsatllPath}) before either of our browsers get it and both browsers would not download updates.
- A malicious application could create the Desktop Firefox started mutex (esktopFirefoxStarted-{HashOfInsatllPath}) and prevent updates from the Metro side.  The Desktop side would still be able to do the updates though.

Comment 9

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

We can try to cover this today, if we need another meeting we can figure that out.

Comment 10

[Brian R. Bondy [:bbondy]]

Better Sync setup for Metro
===========================

To keep the Desktop and Metro profiles in sync we are using Firefox Sync at the moment.
Currently a user can manually setup sync on both browsers, but this is not the best experience.
We would like to improve the setup process so that a user only has to setup sync on only the Desktop side.
This feature is just in the scoping/planning phase but we'd appreciate feedback from security.

To do this automatic sync-setup-in-Metro, we want to apply one of these 2 solutions:

1. If technically possible, from the Metro browser, we want to try to snoop on the info of the Desktop profile and copy out the username, password and encryption key for sync from the password manager.  This has not been investigated yet, but may not be possible due to some other security measure or due to in-use errors.
2. If that's not possible though, at sync setup time on the Desktop side, we want to copy that information to a secure location (username, password, encryption key).  Then from the Metro profile, access that securely stored information.

If #1 is not possible, does anyone have ideas about the most secure way to do #2?
Is storing this information with ACL's specified that only the current user can read the info enough? (No)
Is there a way to stop other processes being run from the same user to access this information?  Maybe they already can with the password manager.

Comment 11

[Brian R. Bondy [:bbondy]]

In Comment 8:
:%s/Firefox-{HashOfInsatllPath}/DesktopFirefoxStarted-{HashOfInsatllPath}/g

Comment 12

[Brian R. Bondy [:bbondy]]

Potential phishing concerns in Metro 
====================================

The Metro browser will be full screen, and no URL will be shown most of the time when viewing pages.
A gesture or keyboard shortcut can be used to show the URL bar and tab bar though.

When the user clicks on a link and a page is loading, we show the URL bar to indicate the URL of the changed site.
The user can switch tabs without the URL bar showing.

Questions for security:
1. Are there any times that a URL bar should be shown?
2. We don't currently have a lock icon or other indication that the user is on a secure site.  This is not yet implemented but there is a bug posted for it.  Is this a blocker for landing anywhere?
3. We don't currently have a notification that the user is on a partially secure site. Same questions.
4. We don't currently display certificate information about a secure site
5. Is there any places that you think the URL bar should be shown that I haven't mentioned (and possibly forgot to mention)?
6. Is it a concern that a malicious page could be designed to look like our URL bar and fake the user visiting different sites? Is there any way to prevent that?


Suspend Resume
==============

A browser process can be suspended and resumed at any point by the OS when the process is not in use.
A process suspend usually happens a few seconds after the user switches away from the browser.

No code will be running when this happens from the Firefox process.
Since this is something that never happens to the normal Firefox Desktop process, I wanted to bring it up in case there are important things that must run in the background while the browser is open.

Comment 13

[Brian R. Bondy [:bbondy]]

Last message :)

Other potentially useful information
====================================
- The only plugin we plan to support initially is Flash
- Addons will not be supported initially at all
- The Metro process itself runs as a medium integrity process which is the same as the Desktop process, but higher than every other application which runs as App Container.
- The Metro Firefox browser can only be used if it is the default browser.  Only 1 browser on the system can be the default and therefore only 1 browser is allowed in as the Metro browser.

Comment 14

[Jim Mathies [:jimm]]

(In reply to Brian R. Bondy [:bbondy] from comment #13)
> - The only plugin we plan to support initially is Flash

FWIW, this depends, Adobe needs to make changes to their plugin before we enable it. We are in discussions with them but thus far we haven't gained a commitment from them. If we do support flash, it will be windowless only, and will run out of process.

Comment 15

[Jim Mathies [:jimm]]

Telemetry bug related to metro - bug 828562

Comment 16

[Brian R. Bondy [:bbondy]]

Bug for reviewing file launching bug 828768