DLL Hijacking "jansi.dll"

[dalvarezperez]

Describe the bug
Ghidra 9.0.1 is vulnerable to DLL hijacking because it loads, at least, "jansi.dll" from the working directory instead of loading it from the right directory where it is expected to be.

To Reproduce
Steps to reproduce the behavior:

1. Compile the following code and name the resulting binary file as "jansi.dll":

#define DLLIMPORT __declspec(dllexport)
#include <windows.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason,LPVOID lpvReserved)
{
	WinExec("calc", 0);
	return TRUE;
}

2. Execute Ghidra from the working directory where the resulting "jansi.dll" do exist.
3. "calc.exe" file will get executed.

Expected behavior
Load "jansi.dll" from the rigth directory where it is expected to be.

Screenshots

Environment (please complete the following information):

• OS: Microsoft Windows 7 x64 version:6.1.7601
• Java Version: 1.8.0_121
• Ghidra Version: 9.0.1

Additional context
In practice, vulnerability can be exploited, for instance, if the user launches Ghidra Projects from the contextual menu and it comes with a malicious "jansi.dll" file.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.gpr\shell\ghidra\command]
@="\"C:\\Program Files\\ghidra_9.0.1\\ghidraRun.bat\" \"%1\""

[ryanmkurtz]

Is this another jython thing? I see jansi.dll is bundled in the jython jar. Does it only load the dll when our python interpreter is initialized? Thanks!

[dalvarezperez]

As shown in the screenshot, "jansi.dll" is loaded when Ghidra is started. It is not necessary to access the Python interpreter.

[ryanmkurtz]

It looks like log4j might be the culprit here. Could you try adding VMARGS=-Dlog4j.skipJansi=true to your support/launch.properties file to see if it corrects the behavior for you?

[ryanmkurtz]

I went ahead and added VMARGS=-Dlog4j.skipJansi=true to support/launch.properties for our next release. Let us know if you continue to see issues...if so I'll reopen the ticket.