961676 - (CVE-2014-1520) Unsafe temp directory usage in maintenservice_installer.exe lead to possible privilege escalation

Status: VERIFIED FIXED

(Firefox :: Installer, defect)

Description

[Holger Fuhrmannek]

Attachment: poc.rar

I have seen the following behavior with windows 7 32bit and the maintenservice_installer.exe which is for example executed during an update process with the mozilla maintenance service.

The installer creates during execution a file with the following name format and executes the file:

C:\Windows\Temp\ns{random character a-z generated with GetTickCount%26}{16bit hex value from GetTickCount()}.tmp\ns{16bit hex value from GetTickCount()}.tmp

For example: C:\Windows\Temp\nscFF1B.tmp\nsFFCA.tmp

It is possible to force the executable to load dlls from the current directory with an „executable.local” dirctory in the directory of the executable (windows specific feature). 
For the example with a ”C:\Windows\Temp\nsFF1B.tmp\nsFFCA.tmp.local” directory, the dlls loaded from the nsFFCA.tmp executable will be first searched in the nsFFCA.tmp.local directory, then in the nscFF1B.tmp directory and at least at the system path.

Because the temp directory is writable for normal users and the path is easy to  guess because of the use of GetTickCount() there is a privilege escalation vulnerability.

POC:

To try out the poc you need firefox 26.0 with the maintenance service installed and a 32bit windows.  I used windows 7. My poc tries to force the executable to load a fake mcrvrt.dll from the directory to start a calc.exe with system rights. Because of GetTickCount() this attack is timing dependent.

Steps:

1.) download poc and extract the files
2.) copy the updater.exe from the firefox directory to the poc/update directory
3.) download http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/26.0/update/win32/en-US/firefox-26.0.complete.mar and save the file as update.mar in the poc/update directory
4.) alter the paths in update.bat to your paths
5.) start poc.exe
6.) start update.bat
7.) wait for output from poc.exe
8.) check for calc.exe
9.) if no calc.exe found, start update again

With windows 7 64bit no executable is loaded in the temp directory, so this will not work but maybe there is another way. Maybe the source of this vulnerability is in the nullsoft installer system and not in the script to create the installer, so maybe it's a general nsis problem.

Comment 1

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

I've asked Brian to take a look.

Comment 2

[Brian R. Bondy [:bbondy]]

I'm not sure why the maintenservice_installer.exe installer does this, it's definitely not something we do manually in NSIS script.  I think the safest way to get around this is to not run a binary created from an NSIS script and to just do the steps manually inside updater code.

Comment 3

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

Hey, Brian, can you take this? I know there are several issues around maintenance service.

Comment 4

[Brian R. Bondy [:bbondy]]

(In reply to Al Billings [:abillings] from comment #3)
> Hey, Brian, can you take this? I know there are several issues around
> maintenance service.

Yes, which issues?

Comment 5

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

I don't recall. Stream of bug consciousness says you and Rob have looked at / are working on various issues with the installer and maintenance service security.

Comment 6

[Brian R. Bondy [:bbondy]]

I ask because we're considering removing the pref for whether or not to use the maintenance service in another bug.  We consider the maintenance service to be more secure in some cases.

You mentioned that you know of several issues around the maintenance service, and if that is the case, please ping me on them because they will factor into the above decision. 

(In reply to Al Billings [:abillings] from comment #5)
> I don't recall. Stream of bug consciousness says you and Rob have looked at
> / are working on various issues with the installer and maintenance service
> security.

The installer and the maintenance service are very different things.

Comment 7

[Brian R. Bondy [:bbondy]]

rstrong and I discussed this bug.

- Removing the maintenance service pref probably wouldn't have any benefit because they could disable the maintenance service if they really wanted to in other ways like simulating failed updates so it falls back to not using the service.
- The only known way to fix this, is very risky and would probably affect update uptake in general.
- If we implemented this bug the secure way, and accepted that there would be a decrease in update uptake, this would introduce a new security issue that someone could easily stop updates from happening by simply opening a handle to the firefox update directory.  In which case we wouldn't be able to lock it and would fail the updates.
- We should check on new OS releases to make sure no new dlls are being injected to updates.

Since this bug has no known exploits, we think it is better to close as WONTFIX.  
The only known way to fix this in general is to do 1-off fixes like we've been doing.

If there is any disagreement please feel free to re-open for discussion.

Comment 8

[Brian R. Bondy [:bbondy]]

That comment was meant for bug 884806

Comment 9

[Brian R. Bondy [:bbondy]]

Attachment: patch v1.

Does the maintenance service upgrade via the same method as the maintenance service installer. I.e. copies the installdir's maintenance service to maintenanceservice_tmp.exe alongside the maintenance service. Then executes it with the upgrade command line param.

It doesn't update the registry with new maintenance service info on upgrades, but this info is not correct anyway already.  Cleanup for not showing the version in registry should be done in a different bug that is reported about that (it exists already)

Comment 10

[Brian R. Bondy [:bbondy]]

Comment on attachment 8397948 [details] [diff] [review]
patch v1.

Approval request for landing on Oak for testing and on mozilla-inbound.


[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Hard to tell what the change is for.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
I don't think so.

Which older supported branches are affected by this flaw?
All since the maintenance service in bug 481815

If not all supported branches, which bug introduced the flaw?
n/a

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
Backports should be the same

How likely is this patch to cause regressions; how much testing does it need?
Low

Comment 11

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

Comment on attachment 8397948 [details] [diff] [review]
patch v1.

sec-approval+. Let's get this on Aurora, Beta, and ESR24 if it works fine on trunk.

Comment 12

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/24123c2951c5

Comment 13

[Brian R. Bondy [:bbondy]]

Comment on attachment 8397948 [details] [diff] [review]
patch v1.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 481815
User impact if declined: local privilege escalation attacks can be exploited due to nsis
Testing completed (on m-c, etc.): Will land later today, after a couple days of updates it'll be safe. Manually tested on Oak.
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none.

Comment 14

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/24123c2951c5

Comment 15

[Brian R. Bondy [:bbondy]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/bfd99c9d0c47

Comment 16

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7215a496c2ad

Comment 17

[Brian R. Bondy [:bbondy]]

http://hg.mozilla.org/releases/mozilla-esr24/rev/58473d4a434a

Comment 18

[Kamil Jozwiak [:kjozwiak]]

I've reproduced the original issue using the STR and the POC in comment #0 (Win 7 x86 using FF 26). I noticed that the calc.exe was runing under maintenanceservice_installer.exe using session 0. (used Process Explorer)

* Nightly:
- build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-23-03-02-02-mozilla-central/firefox-31.0a1.en-US.win32.installer.exe
- mar: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-23-03-02-02-mozilla-central/firefox-31.0a1.en-US.win32.complete.mar

* Aurora:
- build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-23-00-40-03-mozilla-aurora/firefox-30.0a2.en-US.win32.installer.exe
- mar: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-23-00-40-03-mozilla-aurora/firefox-30.0a2.en-US.win32.complete.mar

* BETA:
- build: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/29.0b9/win32/en-US/Firefox Setup 29.0b9.exe
- mar: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/29.0b9/update/win32/en-US/firefox-29.0b9.complete.mar

* ESR 24:
- build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/24.5.0esr-candidates/build1/win32/en-US/Firefox Setup 24.5.0esr.exe
- mar: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/24.5.0esr-candidates/build1/update/win32/en-US/firefox-24.5.0esr.complete.mar

Went through all of the above builds using the STR and the POC from comment #0 several times (5x on each build) and couldn't reproduce the original issue. maintenanceservice_installer.exe is launched using session 0 and then updater.exe right beneath it. The maintenanceservice_installer.exe process than disappears and calc.exe doesn't launch.