Security/Reviews/Firefox10/SilentUpdateEliminateWait

Items to be reviewed:

• https://bugzilla.mozilla.org/show_bug.cgi?id=307181

Introduce Feature

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

• need to make update silent and in the background to improve user experience
• https://wiki.mozilla.org/Background_Updates

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

• the chrome approach - having two versions side by side and picking the latest one
  • this breaks things that rely on our installation directory being fixed
• applying update on shutdown rather than start up - not planned currently

Why was this solution chosen?

• works better
• do not want to completely rearchitect how Firefox launches just to get silent updates

Any security threats already considered in the design and why?

• not adding lots of new stuff
  • changes are to interactions between them
  • biggest change is in copying files

Threat Brainstorming

• Race conditions during copying
  • we don't rename anything until we have two fully working versions
• Folders/files being locked during rename/copying operations
• dealing with issues of crash/fail during update
  • update.status is updated to track changes and monitor state
  • if a failure state is detected old directory is removed completely and created from scratch
• Will Antivirus software freak out because of this relatively unusual behavior?
  • likely caught when landed in nightly if there is an issue
    • ZoneAlarm ForceField, TripWire
• how do we verify we have a complete and proper copy?
  • status file = applying -> update is progressing, if halted in this state then we may have a failure we need to restart
  • if anything fails we bail out and write an error code to the file to notify the main firefox instance
  • only in success does update.status get changed to success

Conclusions / Action Items

• [QA] If we have a comprehensive plan for "noisy" updates does that cover us for "silent" updates? Are there security "holes" we should be testing for?
  • I think a lot of the testing will have to be repeated for the silent case and the noisy case.
  • Failure of the silent case that should fall back to the noisy case needs to be tested