From MozillaWiki
Jump to: navigation, search

Items to be reviewed: How we should implement the verification that the stub installer has downloaded the correct file for installing Firefox

Introduce Feature

Stub installer installation process

1. download stub installer.

  • hosted on a Mozilla web property using https.

2. are installation files present?

  • installer and stub installer are the same binary.
    • if installation files are present perform installation - End.
    • if installation files are not present download the full installer.
  • the same url is used to download all versions and uses bouncer to get the latest. I believe some work will need to be done to bouncer to support this.
  • when Windows x64 Firefox is official the stub installer will download the x64 version of Firefox on Windows x64. I believe some work will need to be done to bouncer to support this.
  • the download starts as soon as possible after the stub installer is launched to lessen the time it takes to complete the installation.
  • download is performed in the unelevated process if applicable. This will require additional work since we need to communicate between the two processes and provide progress updates from the unelevated process to the ui process - how important is this?
  • the stub installer will send back stats regarding the mirror used, if the installation was successful, how long it took to download, the amount downloaded, and the step in the installer where the user exited the installer (additional data points?).

3. after download completes - is the full installer's certificate valid and has the expected attribute values (OU and CN - others)?

    • no, warn user (provide alternative installation path) - End.
      • needs flushing out with UX.
    • yes, extract installation files compressed using lzma (7-Zip self extracting archive to be exact).

4. perform installation - End.

UX Design for the installer and stub installer (rob is waiting for updated design or text for the "marketing" parts?)

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

  • A stub installer would allow us to use TLS to serve the installer, reducing risk of MITM or mirror compromise.
  • Fewer separate long "waiting" steps: "downloading" and "installing" are combined.
  • Optionally, lets us parallelize install questions (e.g. install location) with the download. But NSIS threading is sketchy.

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

  • This is a replacement for our current process of shipping a full install rather than a stub

Why was this solution chosen?

  • best path

Any security threats already considered in the design and why?

  • MITM
  • https CA system compromise
  • files hashed and hash check before install : spoofing
  • versions are checked

Threat Brainstorming

  • Temp directory concerns (not new)
    • Temp directory races
    • Temp directory permissions
    • Confusion about whether core/source exists (accidentally turning stub installer into full installer or vice versa)
  • Server gives you an old version of Firefox (which is also signed, and would pass validation) ("downgrade attack")
    • Perhaps Bouncer could give us a hash of what to expect. This connection is wininet-SSL, so it's at least a somewhat trusted channel. But it's extra complication.
    • Perhaps the stub installer could know what version it expects to download. Is it extra work for releng to put up a new version of the stub installer when we do a point release of Firefox?
  • User has an outdated stub installer (or even an outdated full installer)
    • Warn?

Conclusions / Action Items

  • [rob] version check for downgrade attack (discussion with mrz)
    • connections with HTTPS
    • cert checks
  • [rob & bsmith] specific valid root
  • [rob] download unelevated
  • [jesse] follow up on unanswered threat brainstorming questions and post responses to wiki
  • [rob] follow up with privacy on metrics data they want to gather
  • [secteam] code review of the installer