902771 - Can't execute updater.exe under default AppLocker and SRP configuration

Status: NEW

(Toolkit :: Application Update, defect)

Description

[Masatoshi Kimura [:emk]]

(Quoting from bug 711475 comment #97)
> > The bug from yesterday is something different. For security reasons, 
> > users in our Domain are only allowed to execute files in 
> > C:\Program Files (x86). In the AppLocker Eventlog i found 
> > that Firefox tried to execute updater.exe in 
> > %OSDRIVE%\USERS\TESTUSER\APPDATA\LOCAL\MOZILLA\UPDATES\EEFEA8717BC47F65\UPDATES\0\ 
> > under the context of my User who does not have the right to 
> > execute files here. Can't the maintenance service run this 
> > exe as the SYSTEM user?
> 
> The reason we don't execute the updater.exe inside program files, is because
> it's in use to do the update.  When the maintenance service is in use here
> is the sequence of events:
> 1. Firefox executes updater.exe to do the upddate inside appdata (low
> integrity process)
> 2. Low integrity updater.exe asks the maintenance service to do an update
> 3. maintenance service copies updater.exe inside the maintenance service
> directory inside program files.
> 4. maintenance service executes updater.exe inside the maintenance service
> to do the update. 
> 
> Perhaps you could configure it to only allow executing high integrity
> processes inside program files, but allow low integrity processes to execute
> anywhere, then the issue would go away.   If not please file a new bug and
> we can discuss it there.

Comment 1

[Masatoshi Kimura [:emk]]

Is it possible for Firefox to ask the maintenance service directly to copy and execute updater.exe?

Comment 2

[Brian R. Bondy [:bbondy]]

Technically, yes I think that would be possible. I think this is a pretty risky change though.

Comment 3

[Alexander Lackner]

After allowing Users to execute updater.exe in the following Folders via an AppLocker rule i was able to apply the update without admin-rights:  

C:\Users\*\AppData\Local\Mozilla\updates\*\updates\0\updater.exe
C:\Users\*\AppData\Local\Temp\Mozupdater\bgupdate\updater.exe

A lot of companies should have problems with this because the default AppLocker configuration only allows users to execute files under C:\Program Files and C:\Windows as seen on this website: http://technet.microsoft.com/en-us/library/ee460956%28v=ws.10%29.aspx

The Folder to use would be C:\Windows\Temp because this is the only folder where the User can write and execute Files when the Default AppLocker configuration is active.

Comment 4

[Alexander Lackner]

Please change the Title/Description to something like "Can't execute updater.exe under default AppLocker configuration". The Title as it is now makes it seem as if this only applies to a certain AppLocker configuration. 

The real problem here is that every user in a company which has the default AppLocker configuration set to active is not able to update Firefox unless they start it as an admin.

Comment 5

[Richard van den Berg]

Please note that using the AppLocker path rules in comment 3 are insecure. The general idea of using AppLocker is to prevent execution from folders that are writable by standard users. Using an AppLocker hash rule is much safer, but it would need to be updated every time updater.exe changes. If updater.exe is signed, a signature rule can be used which is safer than a path rule, but less safe than a hash rule.

Comment 6

[Alexander Lackner]

(In reply to Richard van den Berg from comment #5)
> Please note that using the AppLocker path rules in comment 3 are insecure.
> The general idea of using AppLocker is to prevent execution from folders
> that are writable by standard users. Using an AppLocker hash rule is much
> safer, but it would need to be updated every time updater.exe changes. If
> updater.exe is signed, a signature rule can be used which is safer than a
> path rule, but less safe than a hash rule.

If the Update would be applied in "C:\Windows\Temp" no AppLocker rule would be needed. I am currently thinking of shipping the next Firefox version with a signature rule, tested this already and it works perfectly when applying the update as a limited user.

Comment 7

[Richard van den Berg]

Yes, the default AppLocker rules allow execution from "C:\Windows\Temp". However, "C:\Windows\Temp" is one of the first directories that are removed (exception to the default rule) when the rules are edited by an administrator. It would however solve this particular problem which concerns the default rules only.

Comment 9

[Brent R]

The same issue applies to SRP (Software Restriction Policies) -- AppLocker is simply a new name for a later version of the software which is currently only available in Enterprise and Ultimate editions of Windows 7 to 8.1 (whereas SRP is available in Professional edition and up from XP to 8.1).

Bug name should be updated accordingly.