canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/Reviews/Firefox10/SilentUpdateOSDialogs: Difference between revisions
Jump to navigation
Jump to search
Security/Reviews/Firefox10/SilentUpdateOSDialogs (view source)
Revision as of 17:37, 7 December 2011
, 7 December 2011no edit summary
(Created page with "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 == ===...") |
No edit summary |
||
| Line 1: | Line 1: | ||
=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 | Items to be reviewed: Silent Update | ||
https://wiki.mozilla.org/Windows_Service_Silent_Update | https://wiki.mozilla.org/Windows_Service_Silent_Update | ||