1552206 - Permissions overwrite via folder symlink TOCTOU by Maintenance Service

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[Seb Patane (he/him)]

Attachment: proof-of-concept.zip

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 68.0.0.7074 of the maintenanceservice.exe.

[0] - https://dxr.mozilla.org/mozilla-central/rev/cb5734727c0a9d88e3e236a3e4a741a051509e0e/toolkit/mozapps/update/common/commonupdatedir.cpp#1040
[1] - https://dxr.mozilla.org/mozilla-central/rev/cb5734727c0a9d88e3e236a3e4a741a051509e0e/toolkit/mozapps/update/common/commonupdatedir.cpp#1071

Comment 1

[Daniel Veditz [:dveditz]]

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

Comment 2

[Molly Howell (she/her) (mostly inactive)]

Kirk is working on this.

Comment 3

[Robin Steuber (she/her) [:bytesized] (Out until April 4)]

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

Comment 5

[Daniel Veditz [:dveditz]]

Patch landed with the fix for bug 1551913:
https://hg.mozilla.org/mozilla-central/rev/d02282987e93cfa67b7bfc6bb575c734b332af4c

Comment 6

[Ryan VanderMeulen [:RyanVM]]

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

Comment 8

[Al Billings [:abillings - ex-MoCo]]

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

Comment 9

[Catalin Sasca, Desktop Test Engineering [:csasca]]

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

Comment 10

[Robin Steuber (she/her) [:bytesized] (Out until April 4)]

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.

Comment 11

[Catalin Sasca, Desktop Test Engineering [:csasca]]

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