Closed Bug 435711 Opened 12 years ago Closed 11 years ago

High-privilege token assigned to Firefox process after update


(Toolkit :: Application Update, defect)

Windows Vista
Not set





(Reporter: pawel.jasnos, Assigned: rstrong)




(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008052506 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008052506 Minefield/3.0pre

This probably occurs in all versions of Firefox, but is really visible in Minefield as updates are very frequent. When updater is launched, Vista recognizes it as a setup program and asks user to launch it with administrative rights via consent.exe . After updater finishes its job, it launches firefox executable without dropping priviledges (or using user token as opposed to administrator token). This occurs both when Firefox is restarted in order to apply the update and when it is started normally after background update (when updater is launched prior to Firefox). makes any vista's "security enhancements" useless, as both Firefox and any of it's child processes run with token having very high privileges.

Reproducible: Always

Steps to Reproduce:
1. Update Firefox (or wait for update).
2. Restart it when prompted.
3. Accept UAC prompt for updater.exe
4. Verify token privileges for Firefox.exe with Process Explorer (or try to download and then run from firefox any executable file).
Actual Results:  
Firefox runs with token having administrative privileges.
makes any vista's "security enhancements" useless, as both Firefox and any of it's child processes run with token having very high privileges.

Expected Results:  
Updater.exe should do it's job and then remove unneccessary priviledges from the process token before starting firefox (not perfect but easier to implement) or grab the actual user token from explorer.exe (this would be better as limited user may launch processes as administrator by entering a password in UAC prompt, and if the process token belongs to an administrator, instead of asking for a password, UAC most probably will only display a continue button, allowing to obtain token with administrative rights without entering password by a limited user).

A simple workaround for this is to never use Firefox session started by updater.exe. Just close it after it shows up and start it again (this may be annoying in Minefield, being updated few times a day, but should be alright for normal Firefox users)
cc'ing rstrong
This is the code which should be dropping elevated privileges:

Pawel, what testcase/evidence shows the elevated privileges for Firefox?
Updated Minefield to most recent version.
This code will still use standard create process if LaunchAsNormalUser fails:
Yes of course it will, for Windows XP compatibility.

I'm not a vista security expert: which entry in the screenshot is the one which indicates that we're doing something incorrectly?
In the lower pane of the screenshot, there is a list of privileges assigned to the token (some of them are disabled, some are not). If a privilege is present on this list, it means it can simply be enabled with AdjustTokenPrivileges and used. On the list you can see, SeDebugPrivilege is listed (the most close equivalent in the UNIX world is euid =0), which allows to bypass any windows security checks on processes, threads etc. (process holding it can use it for instance to inject code into winlogon or smss or any other windows processes). There is also a lot of other privileges present in the token (like SeBackupPrivilege, which allows reading any files on hard-disk by bypassing any security attributes or SeRestorePrivilege, which allows to write to any file on disk bypassing security check). 

Possible implications are that if someone uses any other bug in firefox or any of the plugins that are loaded by it, it would mean a complete system compromise with these privileges (and there would be no UAC prompt asking for user's permission) instead of compromising just the user's profile. Even if someone is using standard user account, this can still affect them if they type-in administrative credentials when they are asked for it by the system in response to updater trying to write something to Program Files.

One of the main purposes of User Account Control is to allow user to see when an application tries to do something really bad to the system: in the "correct" scenario, when Remote Code Execution or remote data discovery vulnerability is exploited in Firefox or any of the plugins (Quicktime or whatever), when the hostile code is executing, it can only change things in the user's profile and if it tries to access any of the system-wide files or settings (e.g. by trying to install a new service), the user will be notified that Firefox is trying to change system settings and asked for permission (and I suspect that at least some users will say no if they see this prompt "out of the blue".

The way it currently works, if anyone successfully exploits a bug in Firefox (or a plugin), they can do anything to the system without a single notification to the user. 

There is more information here:

In essence: browser shouldn't be running with privileges *much* higher than rest of user's programs.

A fix could be to divide updating task into two processes - one using admin rights and other one launching Firefox after an update. 
As a side note, LaunchAsLimitedUser may be failing because of SeTcbPrivilege or SeAssignPrimaryToken not being enabled in the parent process.
This will be fixed when bug 437349 is fixed
Assignee: nobody → robert.bugzilla
Depends on: 437349
Ever confirmed: true
This is fixed for me on the trunk with the checkin of bug 437349.

Pawel, would you verify whether this is fixed or not with the latest trunk?
I just installed some older version of trunk and then tried updating to current - the problem was still present (is Firefox running the old, or new updater.exe when updating?), but I will try again tommorow to see if it re-occurs again.
Sorry, doesn't work for me - do you have debug nightly builds so I can have a look? (If not, I'll use release build).
Steps to verify (using Vista Ultimate without changes to the system and Process Explorer from SysInternals)
1. Download and install a previous nightly trunk (e.g. Minefield)
2. Launch Minefield
3. Verify security on the firefox.exe process (see 1st half of screenshot)
4. Check for updates (e.g. Help -> Check for Updates)
5. Apply the update that was found which will cause a restart.
6. Verify security on the firefox.exe process (see 2nd half screenshot)

note: with the patch the LaunchAsNormalUser code path will not be entered since we always pass 0 for needElevation and hence will use CreateProcessW
Pawel, any luck using the steps in comment #13?
Sorry, it doesn't work for me (I'm using current Minefield all the time, but after every update I find firefox.exe running with all the privileges as described above. It is Vista Premium with all the patches from MS, with Kaspersky IS 2009 and a few apps like OpenOffice. I'll try to run it in a debugger today (which may be tricky with UAC kicking in) and try to give you more details as to which function is failing. Is there any chance of getting *.PDB for trunk? I'd rather avoid building it to get it...
We have a symbol server setup:

There's also a source server, but it doesn't currently work with trunk. :-(
(In reply to comment #15)
> Sorry, it doesn't work for me (I'm using current Minefield all the time, but
> after every update I find firefox.exe running with all the privileges as
> described above.
Strange... the only way I could see this happening is if you are launching Firefox using some other method / utility or via Run as administrator. Did you use the link to the nightly in comment #13?
Ok... <ashamed> 
After finding that CreateProcessWithTokenW sets last error to ERROR_SERVICE_DISABLED, I have checked and it turned out that I have Secondary Logon disabled... Sorry for wasting your time, I should've thought of that... (I normally disable as many services as possible to make the system quicker and reduce attack surface, but this one was one too many).
Closed: 11 years ago
Resolution: --- → INVALID
Resolution: INVALID → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.