Closed Bug 1552206 Opened 5 years ago Closed 5 years ago

Permissions overwrite via folder symlink TOCTOU by Maintenance Service


(Toolkit :: Application Update, defect, P1)




Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 69+ fixed
firefox68 --- wontfix
firefox69 + fixed
firefox70 --- fixed


(Reporter: sebbity, Assigned: bytesized)



(Keywords: csectype-priv-escalation, reporter-external, sec-high, Whiteboard: [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?][adv-main69+][adv-esr68.1+][post-critsmash-triage])


(1 file)

5.75 KB, application/x-zip-compressed
Attached file

When running the Windows Mozilla Maintenace Service's fix-update-directory-perms command there is a race condition between the time when a directories attributes are checked for symlinks/junctions [0] to when the permissions on the file contents of the directory are actually changed [1].

By replacing a valid directory after the call to GetFileAttributesW() with a symlink to a target directory before the recursive call into SetPermissionsOfContent() the maintenance service will be tricked into granting Full Control for the Users group to all files/folders in the target directory.

If we use this to overwrite the permissions of the files in C:\Program Files (x86)\Mozilla Maintenance Service\ folder, we can replace the maintenance service itself with a binary we control and achieve arbitrary code execution as the SYSTEM user.

I've attached a proof of concept + binary which takes a folder path to overwrite the contents' permissions. It's pretty unreliable, but I did have success around the 350ms mark while also running a stress testing tool like Prime95 to slow the system down a bit. I tested this on version of the maintenanceservice.exe.

[0] -
[1] -

Flags: sec-bounty?

For a local user trying to gain admin privs on a locked-down machine, putting the machine under load isn't a stretch.

Type: task → defect
Component: Security → Installer
Component: Installer → Application Update
Product: Firefox → Toolkit

Kirk is working on this.

Assignee: nobody → ksteuber

I'm probably going to end up writing a single patch for this bug and Bug 1551913, which I will post there.

Priority: -- → P1
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?]
Flags: sec-bounty? → sec-bounty+
Group: firefox-core-security → core-security-release

This should be fixed in 69.0b16 due to ship on Friday.

Alias: CVE-2019-11741
Whiteboard: [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?] → [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?][adv-main69+]
Flags: qe-verify+
Whiteboard: [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?][adv-main69+] → [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?][adv-main69+][post-critsmash-triage]
Whiteboard: [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?][adv-main69+][post-critsmash-triage] → [fixed in bug 1551913][reporter-external] [client-bounty-form] [verif?][adv-main69+][adv-esr68.1+][post-critsmash-triage]

Removing CVE because this was fixed by code change in 1551913 so it will go under that bug's CVE.

Alias: CVE-2019-11741

Hi Kirk, can this issue be manually verified by qa? If it is possible, can you provide some STR please? Thanks !

Flags: needinfo?(ksteuber)

Unfortunately, this exploit involves a race condition, so reproducing will be difficult and unreliable. The best STR that I can give you are the ones in the description.

Flags: needinfo?(ksteuber)

Thanks for the infos Kirk, in this situation I will remove the qe+ flag.

Flags: qe-verify+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.