Closed Bug 1574980 (CVE-2019-11753) Opened 4 years ago Closed 4 years ago

Privilege Escalation via Mozilla Maintenance Service if Firefox is Installed to a Writable Location

Categories

(Toolkit :: Application Update, defect, P1)

All
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr60 69+ verified
firefox-esr68 69+ verified
firefox68 --- wontfix
firefox69 + verified
firefox70 + verified

People

(Reporter: hofusec, Assigned: robert.strong.bugs)

Details

(Keywords: csectype-priv-escalation, sec-high, Whiteboard: [post-critsmash-triage][adv-main69+][adv-esr68.1+][adv-esr60.9+])

Attachments

(4 files, 2 obsolete files)

Attached file poc.zip

The full Mozilla Firefox Installer allows a user to choose a custom install location. (Personally I have used this to install firefox on my secondary hard drive at D:\Firefox.)
The installer doesn't adjust the rights of the created firefox directory, so for example, if the user chooses a writable location the firefox directory is writable after the installation.

A writable firefox directory can be exploited to gain system rights via the mozilla maintenance service. During an update the maintenanceservice.exe from the firefox directory is copied to <mozilla-maintenance-service-directory>/maintenanceservice_tmp.exe and executed from there with system rights. By manipulating the maintenanceservice.exe during a update it is possible to escalate privileges.

POC (tested on Windows 10):

1.) install firefox via the full installer (http://archive.mozilla.org/pub/firefox/releases/68.0.2/win32/en-US/Firefox%20Setup%2068.0.2.exe) to a writable directory for example D:\Firefox
2.) unzip attached zip
3.) download https://archive.mozilla.org/pub/firefox/releases/68.0.2/update/win64/en-US/firefox-68.0.2.complete.mar to <unzipped-direcory>/update/0/update.mar
4.) change the firefox paths in copyloop.bat and mozupdate.bat to the firefox install location
5.) change the path to the update/0 directory in mozupdateservicetest.bat to your path
6.) start copyloop.bat (this will overwrite the maintenanceservice.exe in the firefox directory with a test.exe during the update) and mozupdate.bat (will run the update)
7.) After the update finished you will see that:

  • the test.exe was copied to <mozilla-maintenance-service-directory>/maintenanceservice_tmp.exe.
  • this maintenanceservice_tmp.exe is running as SYSTEM user
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

Off the top of my head, maybe there's some way we can insure the service exe we launch at system level passes some sort of code signing check?

I have already thought of a way to fix this last night.

Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED

Holger, thank you very much for finding and filing this bug!

Comment on attachment 9087338 [details]
Bug 1574980 - Fix issues with maintenance service install. r=bytesized

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Not sure.
  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
  • Which older supported branches are affected by this flaw?: All
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?: Easy
  • How likely is this patch to cause regressions; how much testing does it need?: Unlikely. The patch uses an existing check that is used to verify it is ok to launch other binaries such as helper.exe (e.g. the post update process).
Attachment #9087338 - Flags: sec-approval?

Comment on attachment 9087338 [details]
Bug 1574980 - Fix issues with maintenance service install. r=bytesized

sec-approval+ for mozilla-central.

Attachment #9087338 - Flags: sec-approval? → sec-approval+

Comment on attachment 9087338 [details]
Bug 1574980 - Fix issues with maintenance service install. r=bytesized

Beta/Release Uplift Approval Request

  • User impact if declined: Clients will be vulnerable to this exploit
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce: I've verified and if it is desired to have additional verification there are steps in comment #0
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch uses an existing check that is used to verify it is ok to launch other binaries such as helper.exe (e.g. the post update process).
  • String changes made/needed: None
Attachment #9087338 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9087338 [details]
Bug 1574980 - Fix issues with maintenance service install. r=bytesized

Thanks for the fix. Approving this for 69.0b16 now so we can get a bit of wider testing before next week's RC.

Attachment #9087338 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attached patch bug1574980-followup (obsolete) — Splinter Review
Attachment #9087501 - Attachment is obsolete: true
Attachment #9087507 - Attachment is obsolete: true

The followup fixed the Windows MingW build failures

Comment on attachment 9087338 [details]
Bug 1574980 - Fix issues with maintenance service install. r=bytesized

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: Clients will be vulnerable to this exploit
  • Fix Landed on Version: 69
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch uses an existing check that is used to verify it is ok to launch other binaries such as helper.exe (e.g. the post update process).
  • String or UUID changes made by this patch: None
Attachment #9087338 - Flags: approval-mozilla-esr68?
Attachment #9087515 - Flags: approval-mozilla-esr68?

Note: the patch that landed on Beta applies cleanly to ESR68. I will submit a new patch for ESR60 shortly.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: Clients will be vulnerable to this exploit
  • Fix Landed on Version: 69
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch uses an existing check that is used to verify it is ok to launch other binaries such as helper.exe (e.g. the post update process).
  • String or UUID changes made by this patch: None
Attachment #9087559 - Flags: review+
Attachment #9087559 - Flags: approval-mozilla-esr60?
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Comment on attachment 9087338 [details]
Bug 1574980 - Fix issues with maintenance service install. r=bytesized

sec-high fix, approved for 68.1esr

Attachment #9087338 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Attachment #9087515 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Comment on attachment 9087559 [details] [diff] [review]
Patch for ESR 60 - includes the followup fix

... likewise for 60.9
Attachment #9087559 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+
Whiteboard: [post-critsmash-triage]
Alias: CVE-2019-11753
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main69+][adv-esr68.1+][adv-esr60.9+]
QA Whiteboard: [qa-triaged]

I'm trying to reproduce and verify this but I am a bit stuck. In comment 0 at step 4, I should change the path in mozupdate.bat but I don't see that file attached in poc.zip. I figured that it's the same file with mozupdateservicetest.bat but after changing the paths in that file running it does nothing, it just opens a cmd window and closes immediately. Am I missing something?

Flags: needinfo?(robert.strong.bugs)

That was a typo in the steps. It should be
4.) change the firefox paths in copyloop.bat and mozupdateservicetest.bat to the firefox install location
5.) change the path to the update/0 directory in mozupdateservicetest.bat to your path
6.) start copyloop.bat (this will overwrite the maintenanceservice.exe in the firefox directory with a test.exe during the update) and mozupdateservicetest.bat (will run the update)

So copyloop.bat must be started before mozupdateservicetest.bat
copyloop.bat should have overwritten maintenanceservice.exe in the installation directory which you can verify before running mozupdateservicetest.bat

Hope this helps.

Flags: needinfo?(robert.strong.bugs)

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #25)

That was a typo in the steps. It should be
4.) change the firefox paths in copyloop.bat and mozupdateservicetest.bat to the firefox install location
5.) change the path to the update/0 directory in mozupdateservicetest.bat to your path
6.) start copyloop.bat (this will overwrite the maintenanceservice.exe in the firefox directory with a test.exe during the update) and mozupdateservicetest.bat (will run the update)

So copyloop.bat must be started before mozupdateservicetest.bat
copyloop.bat should have overwritten maintenanceservice.exe in the installation directory which you can verify before running mozupdateservicetest.bat

Hope this helps.

Yep it does help, thanks!
I was able to finally reproduce it on a W10 machine, I can see both of the actual results on an affected build (68.0.2):

  • the test.exe was copied to <mozilla-maintenance-service-directory>/maintenanceservice_tmp.exe.
  • this maintenanceservice_tmp.exe is running as SYSTEM user

I verified that the actual results are not seen on builds that contain the fix (Firefox 69.0 RC, Firefox 68.1.0 esr and Latest Nightly 70.0a1). I'll wait for the official esr60.9 to be built and then I'll verify on it as well.

Also verified that this is fixed on 60.9esr as well.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: sec-bounty?
Flags: sec-bounty? → sec-bounty+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.