Open Bug 709738 Opened 13 years ago Updated 2 years ago

helper.exe should not drop system.dll in %TEMP% due to AppLocker not allowing the loading of DLL's from %TEMP%

Categories

(Firefox :: Installer, defect, P5)

Product:
Firefox
Component:
Installer
Version:
8 Branch
Platform:
x86
Windows 7
Type:
defect

Tracking

()

People

(Reporter: richard, Unassigned)

References

Details

Attachments

(1 file)

system.dll.png
88.17 KB, image/png
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

After being prompted by FF to set it as the default browser, I clicked "yes".



Actual results:

FF runs "C:\Program Files\Mozilla Firefox\uninstall\helper.exe" /SetAsDefaultAppUser
The helper.exe drops system.dll in a %TEMP%\nsxxxxx.tmp\ folder 


Expected results:

In environments where executables are restricted by AppLocker, loading DLLs from %TEMP% is not allowed. Please install system.dll in C:\Program Files\Mozilla Firefox\uninstall\ instead of dropping it in %TEMP%
Robert -> Is this installer related?
Yes and it has always been done this way. Though on the surface it seems like something that is simple to fix it won't be.
Summary: helper.exe should not drop system.dll in %TEMP% → helper.exe should not drop system.dll in %TEMP% due to AppLocker not allowing the loading of DLL's from %TEMP%
Are you saying the system.dll is uniquely generated every time it is needed? Loading DLL's from %TEMP% post-install is very bad practice IMHO.
It is extracted every time it is needed and this is how NSIS works.
So the underlying issue is that setting the default browser (a post-install operation) is using the Nullsoft Scriptable Install System. I have no problem with installers, their scripts and temporary DLL's they might call during installation. We ignore those and build our own MSI to distribute to our users. We cannot however allow any arbitrary DLL to be loaded from %TEMP%.

How can we allow our users to select Firefox as their default browser, without compromising security?
I'm not asking you to and I'm not saying this bug shouldn't be fixed.
This behavior makes helper.exe look very suspicious. The security application our company uses asks the user for permission to execute or load DLLs under certain conditions. This appears as "helper.exe", loading "system.dll" from "C:\Windows\Temp\nsxxxxx.tmp\". There are a handful of malwares that user a name like "helper.exe", and it is not clear that this is a Firefox process, so many users will block access to system.dll.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #4)
> It is extracted every time it is needed and this is how NSIS works.

NSIS is a security nightmare. DUMP IT, NOW!
(In reply to Matt Idzik from comment #7)
> This behavior makes helper.exe look very suspicious. The security
> application our company uses asks the user for permission to execute or load
> DLLs under certain conditions. This appears as "helper.exe", loading
> "system.dll" from "C:\Windows\Temp\nsxxxxx.tmp\". There are a handful of
> malwares that user a name like "helper.exe", and it is not clear that this
> is a Firefox process, so many users will block access to system.dll.

It's worse: unprivileged users can (overwrite) "C:\Windows\Temp\nsxxxxx.tmp\system.dll" and gain administrative or even SYSTEM privileges when their malicious DLL is loaded/executed.
(In reply to Richard van den Berg from comment #3)
> Are you saying the system.dll is uniquely generated every time it is needed?
> Loading DLL's from %TEMP% post-install is very bad practice IMHO.

Not only in your opinion.

Take a look at <http://home.arcor.de/skanthak/download/GMAIL.INF>: this script installs a "mailto:" URL handler and handles the show/hide icons and reinstall commands itself.
Why is this "bug", or should I say, bad programming practice, still around, more than five years later, with FF version 45?

Of what use is the mozilla maintenance service, if it is not working smoothly on a computer with applocker or software restriction policies enforced?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

I think this is the same thing I asked about in the support forums https://support.mozilla.org/en-US/questions/1254989#answer-1210474. Today I am seeing AppLocker catch 5 different DLLs running in %TEMP%:
SHELLLINK.DLL
SYSTEM.DLL
CITYHASH.DLL
USERINFO.DLL
APPLICATIONID.DLL

Can someone confirm what all of these are related to? They apparently aren't signed as I tried to whitelist with a publisher rule. If they really only have to do with setting the default browser I'll probably just continue blocking. My main concern is that this behavior has something to do with updates and I want to make sure that part is working properly.

(In reply to user20190402 from comment #12)

I think this is the same thing I asked about in the support forums https://support.mozilla.org/en-US/questions/1254989#answer-1210474.

Yes, what you're seeing appears to be the same thing this bug is about.

Today I am seeing AppLocker catch 5 different DLLs running in %TEMP%:
SHELLLINK.DLL
SYSTEM.DLL
CITYHASH.DLL
USERINFO.DLL
APPLICATIONID.DLL

Can someone confirm what all of these are related to? They apparently aren't signed as I tried to whitelist with a publisher rule. If they really only have to do with setting the default browser I'll probably just continue blocking. My main concern is that this behavior has something to do with updates and I want to make sure that part is working properly.

These are all used by part of the update procedure (as well as by the installer); if they're blocked you'll get a partially complete update, but I can't really make any guarantees about how well that installation will work after that as we don't test or support that scenario at all.

Note that since this bug was filed, NSIS has started configuring the permissions on the temporary directory in question to only grant any access to the Administrators group (assuming the process is running with admin privileges, as all the relevant processes typically are). I believe this should effectively mitigate the possibility for privilege escalation here.

Thanks for the response, Matt. I can't speak to NSIS as I have no experience there, but I don't think they are running as admin. If they were, AppLocker would be allowing them based off the default rule set. As well, I know that Firefox allows a non-administrative user to install the entire application in their AppData. So in that case, how would an administrative hook for maintenance purposes ever get created? That is beside the point really. I have come to accept that certain programs are going to install in this manner, even MS OneDrive does. Therefore a big reason why to use AppLocker.

What you are basically telling me is that in my current state, I should consider Firefox unstable, so I need to get those DLLs whitelisted. I have tried a publisher rule like this:
Publisher: O=MOZILLA CORPORATION, L=MOUNTAIN VIEW, S=CALIFORNIA, C=US
Product name: *
File name: *
File version: *

And the DLLs are still blocked. Does anyone know if these files are digitally signed by anyone? I am going to test hash rules next, but I don't like the prospect of chasing my tail every time the files are updated. This is also not a straightforward process as I have to retrieve the hash from the log, then manually edit the AppLocker xml because the files disappear too quickly to get a copy.

My initial report is not on install or upgrade (users are not allowed to do that in a controlled environment) but upon selecting Firefox as their default browser. That should not require running EXE's and DLL's from %TEMP% at all. If EXE's and DLL's are required for this task please load them from %PROGRAMFILES%.

This is still a problem, the system.dll is not signed and that is the main problem here.

Attached image system.dll.png —
Flags: needinfo?(vegardalsli)

C:\USERS"username"\APPDATA\LOCAL\TEMP\NSVEB98.TMP\SYSTEM.DLL is not signed however.

Flags: needinfo?(vegardalsli)

(I just noticed my previous message and no comment on it - sorry about that. I had meant to say that I believed that we fixed this in https://bugzilla.mozilla.org/show_bug.cgi?id=1751450.)

(In reply to vegardalsli from comment #20)

C:\USERS"username"\APPDATA\LOCAL\TEMP\NSVEB98.TMP\SYSTEM.DLL is not signed however.

Huh. Look at that. None of the other DLLs in the temp directory (eg: CityHash.dll) are signed either, which is extra surprising considering that the only copy of CityHash.dll that we have now is signed and checked into mozilla-central.

What's very interesting is that I get different results from the following two tests:

  1. Unpacking helper.exe manually with 7zip results in signed DLLs.
  2. Running helper.exe and locating the files in the temporary directory results in unsigned DLLs.

However, both files have the same sha256sum, and if I copy the DLLs from the temporary directory elsewhere, they suddenly have a signature.

You're quite right that is clearly still an issue - but whether or not we can do anything about it requires more investigation still.

There seems to be something special about the directories that the NSIS self extractor creates. If I copy the DLLs to another place in %TEMP% (even a directory that I create by hand), the signatures are there. Conversely, if I copy some random exe or dll to the NSIS directory, they appear to lose their signature. I also noticed that explorer.exe stopped showing its application icon in Explorer when I copied that file to the NSIS directory. This leads me to wonder if there's interesting permissions or other metadata on the NSIS directory that cause this?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: