View source for Security/Reviews/Firefox10/SilentUpdateOSDialogs

=2011.12.05=
==Discussion of signing==
Attendees: Ian, Robert, Dan, Ehsan, Curtis, Tanvi, bbondy, Lawrence, Juan, bsmith, clee ...

* Backup plan for silent updates and security concerns over not encrypting the mar file that contains the files and patches to apply the update.
===What are the issues with signing?===
* Signing the mar files now, but we want to do the signature check from the new windows service only and fallback to old update process without signature check if the check fails.  This is because we want to avoid bugs and aren't 100% comfortable with crypto.api. There are some settings that could be part of a domain or local security policy on Windows that could cause verification to fail, and we don't want to block people from getting updated.
* We are not signing today so not introducing a new security issue.
* Security issue is with someone replacing the mar file with a file that is not trusted.
* Local attack from someone on the same machine (the directory that updates is picked up for is world writeable) or a remote attack where a CA has been compromised and can send a different hash in the xml file.
* By signing the mars, dont have to rely on the channel in case there is a CA compromise.
* The directory where work items are written is in appdata and is readable/writeable by any user - existing files are only modifiable by the user who created them, but any user can create a work item here. The updates are downloaded to a directory in the user's profile, which is user-writeable only. 
* Any binary that is run from the Service has an authenticode check.

==Steps:==
* Get AUS and xml; certificate check
* download mar
* check hash
* FF writes status to a file
** (some later time...)
* Start firefox - writes a file to the work item directory?
* Launches the Service
* Service validates authentiocde sig on updater.exe
* Launch update with flag that says check the mar signature
* Validate Mar Signature. 
** SUCCESS -> UPDATE
** FAIL-> Service writes to file to indicate that the user should fallback.
*** FF notices the fail, calls Updater, not Service

* Current method is on startup check for the existence of a pending update and launch the updater and apply it.  As user, may require elevated  privilege, get UAC prompt.  Proposing that don't do the mar sig check on this fallback. In the fall back case, do the update with the updater only, which wouldn't check the mar signature and may give the UAC prompt.  
** (There is a configuration flag that sets signature check to on or off in fallback case?)
* Fallback case proposing that ignore the signature for FF 10, check for FF 11.
* Do we check the Authenticode signature of firefox.exe in the service before we run it? Would this even be useful? We currently do not perform that check.
** Always installed under program files, so if someone can replace it, can replace anything on the system.  Game over situation.  
Anything we do launch, we do check the autheticode sig
* Updater installs the Service. 
* '''Agreement:''' We should add a check for the authenticode cert on the Service.  So for both the installer binary and the Service binary, there will be an authenticode check.
* Can't remove crypto API altogether.  Windows itself has dependencies on crypto API.
* Reason we don't trust crypto API 100%?  Crypto API failures?  Why would you get crypto API failuers from checking authenticode? 
** (admins and local security policy can affect what certs you can use on your local system to do verification)
* FIPs certified. 
* But if crypto API is down your whole box is busted. 
* If crypto API is not working well enough to do the authenticode checks or if there is a bug in the Service, then you could go into fallback mode.
* If we were to fix the mar signature first, then the Service in the next version, wouldn't have this issue.
* When have fallback case, could install a malicious verison of the software.  But since this is just an interim, I don't think we should spend extra effort on this when we are going to remove this case anyway.  Unless we think this fallback logic is going to live for a long time, suggest we don't worry about it.  
* Are we going to add the signature checks in the fallback case for FF11?  How sure are we about this?
* Depends on if have issues with certain systems that can't check the signatures.  Need reports to determine this.
* This is all new code that we have written and doing the best we can to make sure it is correct, but if there is a bug in our implementtion or use of the API that we dont want to lock the users out of updates.  that is something we should know about very soon after deploying it with the fallback logic.  The second is that we shoudl have reporting mechanism that tells us how many fallback cases and what was the error associated with it.
* '''Requriement:''' Agreed that telemetry code would be added before we land the Service on Aurora.
* Service lands tomorrow and marcode signing code will land a few days later.  So the service wouldn't do sig checks on the mar file tomorrow.  In previous security review meetings, agreed that we could land service without siganture checks on mozilla central for nightly builds.  The mar file signing check will take ? days.  Hasn't been reviewed yet, but the patches are there.  
* '''Drivers:''' Product wants to get this into 10.  Damon has also been driving this.  Jay is pushing hard for this.  A lot of the steering committee.  But we want to make a thoughtful decision on this.
** This is close to have a must have for 10, but if the engineering teams not comfortable, then thats another discussion.
* When the service is first installed, is the user alerted about the subverted UAC prompt? (or will this be documented/communicated anywhere ? )
* No user communication.  Some messaging in blogs.  
** Goal is not to get in way of the user. 
** Even in the one-time installation of the Service, there is not going to be any user communication interrupting their install process and letting them know that they will no longer be getting the UAC prompt when updating firefox.
* Ideally, of the signature on the mar fails, we stop and dont do fallback.  But we have some fears of bugs
* If  landed the mar sig check first then the service, then we could rely on the service.  Since we are doing this in the opposite order, we can't.
* For  the average user (and hence for product), the annoyance of the install process is the driving factor, not the security of the install process.  That is why we are doing this kind of backwards.
* '''Conclusions:'''
If have authenticode cert checks on updates after the Service has arleady been installed, then we can get away with not checking the sig on the mar files during fallback for FF10.  Telemetry code will be added before this is landed on Aurora since it is necessary to work out any issues before adding signature check to the fallback case in FF11.


=Previous Meetings=
Items to be reviewed: Silent Update
https://wiki.mozilla.org/Windows_Service_Silent_Update
https://wiki.mozilla.org/Silent_Update_OS_Dialogs 
Agenda: 
== Introduce Feature ==
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) ===
* make silent updates, completly silent & not have UAC prompt
** current displaces a UAC prompt on next restart to run updater.exe
** will install a service to handle this
*** if the user does not have rights then no service and experience remains the same
** Service runs as LocalSystem
*** needed for impersonation into the users Firefox process
** this works on win2k and higher
* there's only one service planned, not one per product
=== What solutions/approaches were considered other than the proposed solution? ===
* considered Google Update service integration
* defaulting to an alternate location (other than Program Files)
** does not need elevation
=== Why was this solution chosen? ===
* want to user service for other things later so this was the best choice
** if limited user than alternate directory is used
** user can choose a different location
* user can start the service without needing admin privs due to the service ACE
=== Any security threats already considered in the design and why? ===
* The service itself gets installed into a secure location
* the updater.exe is signed (or will be) and its authenticode signature will be checked 
== Threat Brainstorming  ==
* use when firefox is not running to download update?
** no
* how do we verify the installation file is correct?
** all the downloading code is the same as it is now
** call updater.exe as we do not
* how is updater.exe verified?
** check on authenticode certificate it is signed with
** all other code paths remain the same
** no additional version check, just check all the same stuff we do today
** update is signed, but a version check is not done (mars is signed)
* extension compatability check
** out of scope for this 
* when the install is done, the user session is returned to and this session ID comes from the work item in the directory so it's possible to end up in a user/attacker controlled session - what can be done in this context ? where is this hardcoded or determined ? (this is called out in the wiki)
** it runs a script that does user specific things like registry settings, command line handlers for protocols etc - checks things are what they should be and fixes them if not - the worst that could happen seems like it could be to fix up another user's shortcuts etc 
* if user has incompat add-ons we ask for them to update
** there is another project to fix add-ons default compatible
** is this addon compat detection part of the privileged code?
* how is IPC between firefox and service secured?
** current writing into program data
** service will only process items with a signed mozilla certificate
* how is service itself updated?
** uses updater.exe, service stops, service updated then restarts (plan)
* the failure mode for things like not being able to start service, can't install 
service because a service with the same name exists, it falls back to the old
UAC prompting updater.exe method
* cert expiration issues. Overlap? Backup certs?
* what crazy things happen if i'm running multiple instances of firefox and one of them decides to update?
== Conclusions / Action Items  ==
* [bsmith] consider possible approaches for storing the signing verification cert(s) securely - registry keys, ini files, etc - either way we can set whatever ACL we want on the key or file
* [bsmith] get more information about how we sign our products
** authenticode for binaries (cert details?)
** specifics on .mar signing (homegrown signatures?)
** specifics on how we determine a signed Firefox is "OK"
** how would a non-Mozilla ship a customized Firefox-based product?
* [imelven] https://bugzilla.mozilla.org/show_bug.cgi?id=481815
** imelven will do a quick implementation review of the Windows service as it is now and stuff in obsolete patches too
* [curtisk] co-ordinate with QA to ensure sensative test cases are covered
** you can contact Anthony Hughes (ahughes) for the time being

[[Category:SecReview|SilentUpdatesOSDialogs]]