Closed Bug 1215648 (CVE-2017-7761) Opened 8 years ago Closed 7 years ago

Maintenance Service helper.exe File Deletion Elevation of Privilege


(Firefox :: Installer, defect)

Not set



Tracking Status
firefox-esr45 --- wontfix
firefox52 --- wontfix
firefox-esr52 54+ verified
firefox53 --- wontfix
firefox54 + verified
firefox55 + verified


(Reporter: hofusec, Unassigned)




(Keywords: csectype-priv-escalation, sec-moderate, Whiteboard: [adv-main54+][adv-esr52.2+])


(1 file)

2.68 MB, application/zip
Attached file
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:
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.
Flags: needinfo?(kjozwiak)
Holger, I'm trying to reproduce this issue using the 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 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
* 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
Flags: needinfo?(kjozwiak) → needinfo?(hofusec)
I'm sorry it should be:
1.) first create the test directory which contains a file named a.txt
Flags: needinfo?(hofusec)
> 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.


- 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?
Flags: needinfo?(dveditz)
Hopefully spohl or mhowell can take this
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.
Flags: needinfo?(dveditz)
Is there a newer version of NSIS that doesn't have this problem?
Stephen, do you have any thoughts on this?
Flags: needinfo?(spohl.mozilla.bugs)
(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.
(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.
Flags: needinfo?(spohl.mozilla.bugs)
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?
Ever confirmed: true
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?
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.
Flags: needinfo?(mhowell)
(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 [] 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.
Flags: needinfo?(mhowell)
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.
Depends on: 1236624
Matt, any progress on updating NSIS? It would be great to get this nine month old sec-high bug fixed. Thanks.
Flags: needinfo?(mhowell)
Per comment #14 that is dependent on bug 1236624. I asked for an update there.
Flags: needinfo?(mhowell)
Hi Matt, 
the patch for bug 1236624 has landed. Does the new version fix this bug?
Flags: needinfo?(mhowell)
configure hasn't been modified to use the new version of NSIS yet so more still needs to be done.
Yeah, it looks like 3.0 beta 1 is being used on the build slaves right now. So we're not there yet.
Flags: needinfo?(mhowell)
Any news or a timeline for bug bug 1236624, Matt? This is a really long standing security bug.
Flags: needinfo?(mhowell)
Sorry for the lack of updates here; yes, there has been some progress. Just left a new comment on bug 1236624.
Flags: needinfo?(mhowell)
The fix for this will need to be in the installer so changing component
Component: Application Update → NSIS Installer
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.
Closed: 7 years ago
Resolution: --- → FIXED
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.
Tracking 54/55 for this sec-high issue.
Group: toolkit-core-security → core-security-release
We're now using NSIS 3.01 for Firefox 54+ and ESR52.2+ \m/
Target Milestone: --- → mozilla55
We should probably have QE verify this.
Flags: qe-verify+
Flags: sec-bounty?
Rating should be sec-moderate to be consistent with other local file deletion bugs facilitated by the maintenance service.
Flags: sec-bounty? → sec-bounty+
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
* 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

* fx54.0b13, buildid: 20170601133324, changeset: 20170601133324

Windows 7 x64 VM - PASSED

* fx55.0a1, buildid: 20170605030204, changeset: 275588f4d852

* fx54.0b13, buildid: 20170601133324, changeset: cb4a4275b365

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.
Whiteboard: [adv-main54+][adv-esr52.2+]
Alias: CVE-2017-7761
Went through the same STR/process as per comment#29 using the following build:
* fx52.2.0, buildid: 20170607123825, changeset: f68e0d98a22a

* Windows 10 x64 VM - PASSED
* Windows 7 Pro x64 VM - PASSED
Group: core-security-release
Component: NSIS Installer → Installer
Product: Toolkit → Firefox
You need to log in before you can comment on or make changes to this bug.