708378 - Authenticode cert check when launching updater.exe

Status: RESOLVED DUPLICATE of bug 1127481

(Toolkit :: Application Update, defect)

Description

[Brian R. Bondy [:bbondy]]

The attack:
This describes an attack without the Windows service.  It is currently exploitable.
An unelevated process could apply an update to any location on the user's hard disk.
If we have the same name as any other file on the system this could be very harmful to the system.
The user thinks a normal update is being applied from a Windows trusted Mozilla UAC prompt.

Current update process:  
1. Update is staged and sits in the user's application directory.
... some time later...
2. On Firefox startup, Firefox launches updater.exe in the user's profile directory to perform an update.
3. updater.exe is run unelevated by Firefox
4. updater.exe unelevated launches updater.exe elevated which gives a Mozilla UAC prompt
5. User clicks yes because they trust Mozilla.
6. Update is applied.
 
The attacker steps:
1. An unelevated attacker simply needs to rename updater.exe to updater_moz.exe.
2. The attacker copies a bad version of updater.exe in the old location.
3. The attacker's updater.exe gets executed at some later time when the user exepects an update to be applied.
4. The attacker's updater.exe simply changes the command line args to have an apply update to directory of some other location than the firefox directory.  The attacker's udpater.exe calls updater_moz.exe.
4. The user gets a UAC prompt for Mozilla and presses yes.
5. The MAR gets extracted to another location possibly causing harm to the system if we have the same named dlls or exes as something else.  

Note: This applies even if the MARs were being signed and checked.

Comment 1

[Robert Strong (they/them - no direct email)]

So, the attacker would need to be able to write to the installation directory? If so, we have talked about requiring users to always install into program files which should already be the case for the majority of users and would mitigate this quite a lot.

Comment 2

[Brian R. Bondy [:bbondy]]

> So, the attacker would need to be able to write to the installation directory? 

No I mean the updater.exe that gets copied into the user's appdata.
I think I thought above it gets copied earlier, but it gets copied just before we run it.
I think if you have a directory watcher though you would have enough time to replace it.

Comment 3

[Brian R. Bondy [:bbondy]]

rs mentioned that not all apps that use updater.exe sign updater.exe.
So a better solution would be around locking the updater.exe file with no write access before running it.
This would be done when copying the file and the handle would be left open until after launching it I think.

Comment 4

[Daniel Veditz [:dveditz] back 2026-04-08]

If the user has permission to replace updater.exe then why does it need to be run elevated at all--doesn't that mean it can do the upgrade with the permissions it already has?

If an attacker can replace our files then just replace Firefox.exe itself, tell the user you need to install something, and run whatever you want elevated because surely the user will click "OK" to the UAC prompt. I guess the whatever wouldn't be signed by Mozilla in that case but I wouldn't pin my security hopes on text in that dialog.

Still, this attack would fool the people who _did_ pay attention and that's bad. I fully support fixing it, it's just not the highest priority problem. For example, without the patch to check MAR signatures the attacker could make -sure- the MAR contained dlls and exes that overwrote system OS files so sig checks are higher priority. Guessing sg:low or moderate?

Comment 5

[Robert Strong (they/them - no direct email)]

This is about the time between nsUpdateDriver.cpp copying the updater.exe over to the staging directory and nsUpdateDriver.cpp launching updater.exe

Comment 6

[Brian R. Bondy [:bbondy]]

> If the user has permission to replace updater.exe then why does it need to be run elevated at all

Any unelevated app run as the user can replace the user's appdir files.
This is more about replacing system files with things in our MARs.  Especially if a system file exists with the same name as something we have.

> If an attacker can replace our files then just replace Firefox.exe itself,

The attacker couldn't replace firefox.exe itself because that is protected in program files.

>  For example, without the patch to check MAR signatures the attacker could make -sure- the MAR contained dlls and exes that overwrote system OS files

Right this situation gets slightly better with signing of MARs.

It is possible we have a dll or exe named the same as a system one though with a signed MAR, I'm not sure about that and I did not verify this.
The attacker could replace some other non windows program though that has the same name as anything in our MAR as well.

I agree with this not being high priority, just wanted to have it on file before I forgot about it.

Comment 7

[Robert Strong (they/them - no direct email)]

bug 1127481 should take care of this as well

Comment 8

[Brian R. Bondy [:bbondy]]

This won't be valid after bug 1127481 is fixed, so closing this.