1215648 - (CVE-2017-7761) Maintenance Service helper.exe File Deletion Elevation of Privilege

Status: VERIFIED FIXED

(Firefox :: Installer, defect)

Description

[Holger Fuhrmannek]

Attachment: poc.zip

The helper.exe creates a directory "ns{random character a-z generated with GetTickCount%26}{16bit hex value from GetTickCount()}.tmp" during execution in the C:\Windows\Temp directory und deletes it later. 
At least in win7 the temp directory is writable for non privileged users. If during the execution a junction is created in the nsXXXX.tmp directory also the content of the target directory of the junction will be deleted from the helper.exe.
With the maintenance service and this vulnerbility it is possible to delete arbitrary files for non privileged users. Further with the ability to delete arbitrary files it´s possible to elevate privilege further.

The poc tries to empty the C:\test directory by creating a junction to it in the C:\Windows\temp\nsXXXX.tmp during the execution of the helper.exe. I have tested it with win7.
1.) first create the test directory which contains a file.
2.) in the updatework directory right to the loop.bat copy the updater.exe from the firefox directory and a current complete update mar file named to update.mar of the target firefox version (for example: https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest/update/win32/de/firefox-41.0.2.complete.mar)
3.) alter the paths in the loop.bat
4.) start the poc.exe and poc.bat and after a short time if the poc.exe is closed the C:\test directory will be empty.

Comment 1

[Kamil Jozwiak [:kjozwiak]]

Holger, I'm trying to reproduce this issue using the poc.zip you provided but I'm not having and luck.. Is there something that I'm missing? Here's the steps that I'm using:

* created C:\test\removeMe.txt
* installed fx 41.0.2
* download the poc.zip from comment #0 and extracted it into "Desktop"
* copied the updater.exe from "C:\Program Files (x86)\Mozilla Firefox\" into "C:\Users\Kamil Jozwiak\Desktop\poc\updatework"
* Downloaded https://ftp.mozilla.org/pub/firefox/releases/latest/update/win32/en-US/firefox-41.0.2.complete.mar
* renamed firefox-41.0.2.complete.mar -> update.mar and placed it into "C:\Users\Kamil Jozwiak\Desktop\poc\updatework"
* Changed the paths in loop.bat to the following:

sc start MozillaMaintenance MozillaMaintenance software-update "C:\Users\Kamil Jozwiak\Desktop\poc\updatework\updater.exe" "C:\Users\Kamil Jozwiak\Desktop\poc\updatework" "C:\Program Files (x86)\Mozilla Firefox" "C:\Program Files (x86)\Mozilla Firefox\updated" -1 /replace "C:\Users\Kamil Jozwiak\Desktop\poc\updatework\updater.exe" 3
goto :m

* launched loop.bat & poc.exe at the same time.

Whenever I run the poc.exe, I get the following output from the start:

>> poc tries empty dir C:\test
>> success!

I tried running the poc.exe several times while loop.bat was running but got the same output as mentioned above. C:\test\removeMe.txt is never removed. I've also checked both "update.status" and "update.log" under "C:\Users\Kamil Jozwiak\Desktop\poc\updatework" and ensured that there weren't any issues related to incorrect paths.

I've also tried this on the following OS's:

* Win 7 x64 VM - Couldn't reproduce
* Win 8.1 x64 VM - Couldn't reproduce
* Win 10 x64 VM -> Couldn't reproduce

Comment 2

[Holger Fuhrmannek]

I'm sorry it should be:
1.) first create the test directory which contains a file named a.txt

Comment 3

[Kamil Jozwiak [:kjozwiak]]

> I'm sorry it should be:
> 1.) first create the test directory which contains a file named a.txt

Thanks, that definitely helped :)

Using the steps from comment #1, I could reproduce the issue. Once I ran the poc.exe, I received the following command prompt:

>> poc tries empty dir C:\test

Launch loop.bat and within 30s-1m, poc.exe will close. Look into C:\test and you'll notice a.txt has been deleted from the directory.

OS's:

- Win 7 x64 VM - Reproduced (a.txt removed)
- Win 10 x64 VM - Reproduced (a.txt removed)

Dan, who should take a look at this? rstrong?

Comment 4

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

Hopefully spohl or mhowell can take this

Comment 5

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

I don't think we can do anything to fix this, because this particular temporary directory is completely managed by NSIS and our code never touches it directly. This is the same directory involved in bug 709738; it's used as a place to unpack the NSIS plugin files into. We may be creating individual files in the same directory, I'm not sure, but if so then we delete those individually by name, so those are not the source of this problem.

Comment 6

[Daniel Veditz [:dveditz]]

Is there a newer version of NSIS that doesn't have this problem?

Comment 7

[Matt Wobensmith [:mwobensmith][:matt:]]

Stephen, do you have any thoughts on this?

Comment 8

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

(In reply to Daniel Veditz [:dveditz] from comment #6)
> Is there a newer version of NSIS that doesn't have this problem?

No; the newest version available is 3.0 beta 2, and it has the same behavior.

Comment 9

[Stephen A Pohl [:spohl] (OOO until 2/27)]

(In reply to Matt Wobensmith [:mwobensmith][:matt] from comment #7)
> Stephen, do you have any thoughts on this?

Unfortunately, if this directory is completely managed by NSIS (as mentioned in comment 5) and there is no newer version of NSIS without this problem (comment 8) I don't have a good solution for this either.

Comment 10

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

Should we close this as "won't fix" if we are unable to fix this issue?
Is there no option to fix this in NSIS?

Comment 11

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

Yeah, the only thing we can do for this is wait and see if a new NSIS release does something about it. There has been a new version, 3.0 beta 3, since I posted comment 8, but I don't see any changes in it that would make a difference here. I assume that means we should WONTFIX this bug, instead of just leaving it alone in hopes of some new NSIS capability materializing?

Comment 12

[Daniel Veditz [:dveditz]]

Matt: Have we reported this problem to NSIS so that they will fix it? If they don't even know we could be hoping for a long time.

Comment 13

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

(In reply to Daniel Veditz [:dveditz] from comment #12)
> Matt: Have we reported this problem to NSIS so that they will fix it? If
> they don't even know we could be hoping for a long time.

NSIS has an issue on file [https://sourceforge.net/p/nsis/bugs/1125/] which includes this and other related points.
It looks like there's been some activity on that issue in recent releases; I'll look into whether this bug has been addressed.

Comment 14

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

I cannot reproduce this bug on a custom build which uses at least NSIS 3.0 beta 3; poc.exe spews out a bunch of error code 5 results (that's the Win32 code for "access denied") and the target file remains in place. It looks like the temp directory is now created with tighter permissions when NSIS detects that it is running elevated.

Since NSIS 3.0 beta 3 fixes this bug, it is dependent on switching automation to (at least) that version, which is bug 1236624.

Comment 15

[Andrew McCreight [:mccr8]]

Matt, any progress on updating NSIS? It would be great to get this nine month old sec-high bug fixed. Thanks.

Comment 16

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

Per comment #14 that is dependent on bug 1236624. I asked for an update there.

Comment 17

[Stephanie Ouillon [:arroway] (needinfo me)]

Hi Matt, 
the patch for bug 1236624 has landed. Does the new version fix this bug?

Comment 18

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

configure hasn't been modified to use the new version of NSIS yet so more still needs to be done.

Comment 19

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

Yeah, it looks like 3.0 beta 1 is being used on the build slaves right now. So we're not there yet.

Comment 20

[Frederik Braun [:freddy]]

Any news or a timeline for bug bug 1236624, Matt? This is a really long standing security bug.

Comment 21

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

Sorry for the lack of updates here; yes, there has been some progress. Just left a new comment on bug 1236624.

Comment 22

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

The fix for this will need to be in the installer so changing component

Comment 23

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

We are now running NSIS 3.01 in automation as of today's nightly build, and as expected the STR no longer work for me with that version.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

I'm going to nominate bug 1347191 and bug 1351482 for Aurora54/ESR52 uplift so we can hopefully get this fixed on those branches as well.

Comment 25

[Marcia Knous [:marcia]]

Tracking 54/55 for this sec-high issue.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

We're now using NSIS 3.01 for Firefox 54+ and ESR52.2+ \m/

Comment 27

[Ryan VanderMeulen [:RyanVM]]

We should probably have QE verify this.

Comment 28

[Daniel Veditz [:dveditz]]

Rating should be sec-moderate to be consistent with other local file deletion bugs facilitated by the maintenance service.

Comment 29

[Kamil Jozwiak [:kjozwiak]]

Before going through the verification process, I ensured that I could still reproduce the original issue with an older m-c that was still using a vulnerable NSIS version. Used the following build:

* fx55.0a1, buildid: 20170401030204, changeset: 00a166a8640d
** https://archive.mozilla.org/pub/firefox/nightly/2017/04/2017-04-01-03-02-04-mozilla-central/
* using the STR from comment#1, "a.txe" was removed from "C:\test"

Once I managed to reproduce the issue as mentioned above, I went through the following verification process:

Windows 10 x64 VM - PASSED

* fx55.0a1, buildid: 20170603030204, changeset: 43039280fe46
** https://archive.mozilla.org/pub/firefox/nightly/2017/06/2017-06-03-03-02-04-mozilla-central/

* fx54.0b13, buildid: 20170601133324, changeset: 20170601133324
** https://archive.mozilla.org/pub/firefox/candidates/54.0b13-candidates/build1/win32/en-US/

Windows 7 x64 VM - PASSED

* fx55.0a1, buildid: 20170605030204, changeset: 275588f4d852
** https://archive.mozilla.org/pub/firefox/nightly/2017/06/2017-06-05-03-02-04-mozilla-central/

* fx54.0b13, buildid: 20170601133324, changeset: cb4a4275b365
** https://archive.mozilla.org/pub/firefox/candidates/54.0b13-candidates/build1/win32/en-US/

Once the fx52.2esr installer becomes available when we get closer to the release date, I'll go through the same verification process as mentioned above.

Comment 30

[Kamil Jozwiak [:kjozwiak]]

Went through the same STR/process as per comment#29 using the following build:
* fx52.2.0, buildid: 20170607123825, changeset: f68e0d98a22a
** https://archive.mozilla.org/pub/firefox/candidates/52.2.0esr-candidates/build1/

* Windows 10 x64 VM - PASSED
* Windows 7 Pro x64 VM - PASSED