1213608 - DLL Hijacking with dbghelp.dll that doesn't exist at Application's Folder

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[YoKo]

Attachment: Process Monitor and Executing the Firefox.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150929144111

Steps to reproduce:

I would like to report an issue and I don't know yet if this issue could be considered as a bug or not.

I. Introduction.
Normally, Firefox (so far I just checked it on v.41.0 and v.41.0.1) load the dbghelp.dll when we executing the Firefox itself. Firefox load those library from X:\<Installation Folder>\Mozilla Firefox\dbghelp.dll and X:\Windows\system32\dbghelp.dll.

As we know, the dbghelp.dll itself is a debug help library that provided by Microsoft Windows OS (please correct me if I'm wrong) and located on X:\Windows\system32\.

The problem in this case is the "dbghelp.dll" file is never putted by the application itself into the application's folder, which is X:\<Installation Folder>\Mozilla Firefox\. In other side, every time the application would like to run, it always tries to execute the dbghelp.dll at the application's folder. With this scenario, Attacker "could put" the malicious dbghelp.dll at the application's folder to "push" the victim to load any malicious code.


II. Affected Version.
So far, the version of Firefox for Windows OS that tested in this related ticket are v.41.0 and v.41.0.1.
As a note, I get the activities that done by Firefox related load the modules from "Process Monitor" tool.


III. Step to Reproduce.
3.1. Create the malicious .dll file, we could create it with msfpayload.
3.2. Change the name of the file to dbghelp.dll.
3.3. Put it into the victim's application's folder. (of course need a user interaction for reproducing this issue. The only thing that we could make sure is the Attacker doesn't need to worry about "replacing" the file that could make the victim realized at the first time, because the file itself is never been there).
3.4. Run the Firefox and Firefox will execute the dbghelp.dll that we put into the application's folder.
3.5. Depends on the code, we Firefox will indirectly execute the code via that dll file.


Actual results:

Firefox will run the "malicious code" from the dbghelp.dll and the result is depends from the code that inserted by the Attacker.


Expected results:

If Firefox only need to load the dbghelp.dll file from system32 directory of Windows OS, so the process of detection and load into the application's folder related this dbghelp.dll should be removed.

Comment 1

[YoKo]

Additional Information:
Tested on Windows XP and Windows 7. It should be has the same result at Windows 8 and 10 too.

Comment 2

[:Gijs (he/him)]

Ted, can you help clarify what's going on here and/or how to fix, and/or if this is necessary (per e.g. bug 797323 and friends) ?

Comment 3

[Daniel Veditz [:dveditz]]

If you can modify the Firefox application directory then you can modify or replace Firefox itself. DLL hijacking is an issue when Firefox tries to load DLLs from directories the attacker can write into, not the victim.

Comment 4

[YoKo]

Totally agree, that's why I wrote on the report that this will use the user interaction and thd problem exist when since the user itself didn't get any warning relates "do you want to replace the file?".

Replacing the firefox is totally diffeerent wwhen you copy something without any warning related the replacing file. Just my opinion. That's why I wrote it that " I don't know yet if this issue couls be considered as a bug or not".

* if user get a warning or popup related the modification of the application itself, then the risk in the user since they allowed such modification to the original executable file. But it would be different when "maybe" they trust if this "dbghelp.dll" file is the needed file for firefox to running. No registry modification, no hardway modification, just put the file directly.

Comment 5

[(not currently active) Ted Mielczarek]

As dveditz says, I don't think this is really a security issue. We probably could link directly to dbghelp.dll, I think it's shipped with Windows for quite a while at this point.

Comment 6

[YoKo]

No objection fron me since I told that don't know too before I got firefox's team explanation. This is just a little miss configuratuon I think.

Thank you very much for your confirmation. And yes, it would be nice if link directly to dbghelp.dll.

Comment 7

[Andrew McCreight [:mccr8]]

Can we unhide this then?

Comment 8

[Stefan Kanthak]

(In reply to yoko from comment #4)
> But it would be different when "maybe" they
> trust if this "dbghelp.dll" file is the needed file for firefox to running.
> No registry modification, no hardway modification, just put the file
> directly.

1. The DbgHelp.dll shipped with Windows and installed in %SystemRoot%\System32\ is not "the real thing", but just a stripped down version of the DbgHelp.dll shipped with Microsoft's debugger. The normal (and documented) way to use "the real thing" is but to copy it in the application directory.

2. If the application directory is properly protected, which is the case when (not only) Firefox is installed below %ProgramFiles%, writing DbgHelp.dll there needs adminstrative privileges. So: no vulnerability then.
If (not only) Firefox is but (ab)used as "portable" application and installed in a user-writable location then DLL hijacking is a well-known PERSISTENT threat: a malicious DbgHelp.dll (and quite SOME more) are not replaced/removed during an update or reinstallation.

Comment 9

[Kim Moir [:kmoir] ET]

Triaging, explanation given in bug, closing.