Closed Bug 1552206 Opened 2 years ago Closed 1 year ago

Permissions overwrite via folder symlink TOCTOU by Maintenance Service

Categories

(Toolkit :: Application Update, defect, P1)

defect

Tracking

()

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

People

(Reporter: sebbity, Assigned: bytesized)

References

Details

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

Attachments

(1 file)

5.75 KB, application/x-zip-compressed
Details
Attached file 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

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
Status: NEW → ASSIGNED

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

Priority: -- → P1
Duplicate of this bug: 1560695
Status: ASSIGNED → RESOLVED
Closed: 1 year 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
Depends on: CVE-2019-11736
Target Milestone: --- → mozilla70

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+]
Duplicate of this bug: 1575289
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.