Security/Reviews/Win8 Metro Firefox

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed

Windows 8 Metro Firefox
Target
   
     Full Query    
ID Summary Priority Status
744928 Windows 8 Metro Firefox Sec Review P4 RESOLVED
747347 Work - [Tracking] Migrate elm work over to mc and integrate win8 metro into fx desktop build/install -- RESOLVED
762344 Move metrofx BrowserApp functionality into firefox's nsBrowserApp -- RESOLVED
771271 Get mochitest-metro-chrome tests running in immersive mode -- RESOLVED

4 Total; 0 Open (0%); 4 Resolved (100%); 0 Verified (0%);

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

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

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • toolkit
    • app updates
      • enable updates on the metro side and the desktop side
    • adding global mutex that that metro side checks
    • skip update if exists due to files in use
    • updates downloaded to a shared location, protected by mutex
      • same location as current updates
    • code to determine which front end to load depending on arguments
  • frontend
  • widget layer
  • exe can launch metro or normal desktop firefox
    • each are different profiles
      • firefox sync used to sync profiles
      • sync is a temporary solution for local profile sync
    • both can be running simultaneously
  • metro desktop
    • launch from start button, runs full screen (or in a "snapped view" alongside another app)
  • windows 8 usually runs process at app container integrity level (lower than low)
    • Metro browsers run at medium integrity ('normal' integrity level, desktop Firefox on Windows 8 also runs at medium integrity level)
  • plugins and addons are pref'd off - hope to support Flash, in particular windowless
  • Metro tries to stop applications from overlaying the Metro interface/UI with their windows
  • Frontend is heavily modified XUL fennec - see elm branch for code
    • code to create child windows has been disabled
    • toolkit is expected to be the first widget created
    • browser is a widget, additional widgets can also be created (nsWindow)
  • Front end tests - new test harness and new test target : mochitest-metro-chrome
    • making progress, high priority
    • new widget backend - need more tests, but it's difficult to test this code without running the full browser, these will need browser-chrome tests
  • No content process yet but running content in a lower privilege (even just low integrity) is desired
  • No private browsing initially
  • Metro code will all land on m-c over next couple weeks, but will be turned off. Needs a new option for mozconfig. Will stay in Nightly and not ride trains for some period of time.
    • Might be on release channel as early as April, maybe over summer 2013

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

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?

Threat Brainstorming

  • creating a window (if an attacker can somehow do it) might end up creating a window on the desktop (not in the Metro view) - we might create a widget but Metro will stop a Win32 window from showing up (IIUC)
  • exploiting Metro process would lead to accessing WinRT APIs as well as win32 APIs, but WinRt APIs are usually more restricted than win32 apis anyways
  • addons / plugins - issues with 3rd party installs enabling extensions
  • exthandler code - popup dialog for 3rd party apps when handling web content, how does metro react to something like this?
  • low integrity app can use one of the "search contracts" and send data to the browser. this is a potential escalation of privilege depending on how the uri is handled.
  • phishing concerns - we are a full screen app and don't always show the URL bar, a site could spoof the firefox interface
    • users can right click or Windows-E or make a magical tablet gesture to show URL bar
  • need to figure out what to do about mixed content for Metro (and Fennec.. and B2G..)
  • Property "SecReview feature goal" (as page type) with input value "* toolkit
      • app updates
        • enable updates on the metro side and the desktop side
      • adding global mutex that that metro side checks
      • skip update if exists due to files in use
      • updates downloaded to a shared location, protected by mutex
        • same location as current updates
      • code to determine which front end to load depending on arguments
    • frontend
    • widget layer
    • exe can launch metro or normal desktop firefox
      • each are different profiles
        • firefox sync used to sync profiles
        • sync is a temporary solution for local profile sync
      • both can be running simultaneously
    • metro desktop
      • launch from start button, runs full screen (or in a "snapped view" alongside another app)
    • windows 8 usually runs process at app container integrity level (lower than low)
      • Metro browsers run at medium integrity ('normal' integrity level, desktop Firefox on Windows 8 also runs at medium integrity level)
    • plugins and addons are pref'd off - hope to support Flash, in particular windowless
    • Metro tries to stop applications from overlaying the Metro interface/UI with their windows
    • Frontend is heavily modified XUL fennec - see elm branch for code
      • code to create child windows has been disabled
      • toolkit is expected to be the first widget created
      • browser is a widget, additional widgets can also be created (nsWindow)
    • Front end tests - new test harness and new test target : mochitest-metro-chrome
      • making progress, high priority
      • new widget backend - need more tests, but it's difficult to test this code without running the full browser, these will need browser-chrome tests
    • No content process yet but running content in a lower privilege (even just low integrity) is desired
    • No private browsing initially
    • Metro code will all land on m-c over next couple weeks, but will be turned off. Needs a new option for mozconfig. Will stay in Nightly and not ride trains for some period of time.
      • Might be on release channel as early as April, maybe over summer 2013" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
      • Property "SecReview threats considered" (as page type) with input value "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?" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    7. Property "SecReview threat brainstorming" (as page type) with input value "* creating a window (if an attacker can somehow do it) might end up creating a window on the desktop (not in the Metro view) - we might create a widget but Metro will stop a Win32 window from showing up (IIUC)
    • exploiting Metro process would lead to accessing WinRT APIs as well as win32 APIs, but WinRt APIs are usually more restricted than win32 apis anyways
    • addons / plugins - issues with 3rd party installs enabling extensions
    • exthandler code - popup dialog for 3rd party apps when handling web content, how does metro react to something like this?
    • low integrity app can use one of the "search contracts" and send data to the browser. this is a potential escalation of privilege depending on how the uri is handled.
    • phishing concerns - we are a full screen app and don't always show the URL bar, a site could spoof the firefox interface
      • users can right click or Windows-E or make a magical tablet gesture to show URL bar
    • need to figure out what to do about mixed content for Metro (and Fennec.. and B2G..)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status In Progress
Release Target `
Action Items
   
     Full Query    
ID Summary Priority Status
829268 Windows 8 Metro Firefox Sec Review: review command execution handler -- RESOLVED
829275 Windows 8 Metro Firefox Sec Review: review frontend code -- RESOLVED
829276 Windows 8 Metro Firefox Sec Review: review updater code -- RESOLVED

3 Total; 0 Open (0%); 3 Resolved (100%); 0 Verified (0%);

  • dchan:: review command execution handler:: When
  • SA :: review updater code
  • Dveditz :: review frontend code
  • dev team:: telemetry data on who is turning on prefs for addons/extenions
  • dev team:: review exthandler code
The given value "
   
     Full Query    
ID Summary Priority Status
829268 Windows 8 Metro Firefox Sec Review: review command execution handler -- RESOLVED
829275 Windows 8 Metro Firefox Sec Review: review frontend code -- RESOLVED
829276 Windows 8 Metro Firefox Sec Review: review updater code -- RESOLVED

3 Total; 0 Open (0%); 3 Resolved (100%); 0 Verified (0%);

  • dchan:: review command execution handler:: When
  • SA :: review updater code
  • Dveditz :: review frontend code
  • dev team:: telemetry data on who is turning on prefs for addons/extenions
  • dev team:: review exthandler code" contains strip markers and therefore it cannot be parsed sufficiently.