Ghidra: Uncontrolled Search Path Element when executing CMD.

[dalvarezperez]

Describe the bug
When executing Ghidra from a given path the Java process working directory is set to this path. Then, when launching Python interpreter located in "Ghidra Codebrowser" -> "Window" -> "Python"
Ghidra will try to execute an arbitrary file "cmd.exe" located at the attacker choosen working directory.

To Reproduce
Steps to reproduce the behavior:

1. Copy an arbitrary Portable Executable file named "cmd.exe" into a folder, for instance: c:\test.
2. Open a command line and go to the choosen folder. Following the same example: cd c:\test\
3. Execute Ghidra from the command line: [route_to_ghidra]\ghidraRun.bat
4. Create a new Ghidra proyect.
5. Add a Portable Executable into the proyect.
6. Open the added file in "GhidraCodebrowser".
7. Go to "Window", and then to "Python".
8. Wait until your arbitrary file "cmd.exe" is executed.

Expected behavior
Ghidra would resolve the right "cmd.exe" located into the Windows system directory.

Screenshots

Environment (please complete the following information):

• OS: Microsoft Windows 7 x64
• Version 6.1.7601

[ryanmkurtz]

I could not reproduce this. The first line of output in your Process Monitor is referencing bin\jython.exe. That is not part of the Ghidra release. Did you add that there? Where you doing anything with Eclipse projects in that jython directory?

[dalvarezperez]

I could not reproduce this. The first line of output in your Process Monitor is referencing bin\jython.exe. That is not part of the Ghidra release. Did you add that there? Where you doing anything with Eclipse projects in that jython directory?

The CreateFile operation result of "bin\jython.exe" is: PATH NOT FOUND because the file, as you known, is not included with Ghidra, in fact, file does not exist but this is not relevant in this case.
Important things here are to execute Ghidra from a choosen working directory where arbitrary "cmd.exe" do exist. You can verify that with Process Explorer. Then, when you launches the python interpreter this file will be unexpectedly executed. Maybe this screeshot helps:

[ryanmkurtz]

Thanks for the additional info. Does it execute your cmd.exe binary every time you reset the python interpreter (ctrl+d or exit() from the interpreter)?

[dalvarezperez]

Thanks for the additional info. Does it execute your cmd.exe binary every time you reset the python interpreter (ctrl+d or exit() from the interpreter)?

Yes, It happens in both cases: CTRL+D and exit()

[ryanmkurtz]

Ok, I'll have to look into why Jython is doing this...it's definitely not necessary for our built-in python interpreter to function. Thanks for finding/reporting this and all of the detailed information!

[ryanmkurtz]

Would you mind sharing the command line arguments that get passed to cmd.exe? Looking at the jython source, it seems to be launching _cmd.exe /c ver_ to get the Windows version (and uname for linux/mac). I want to confirm that is what is happening for you.

[dalvarezperez]

Would you mind sharing the command line arguments that get passed to cmd.exe? Looking at the jython source, it seems to be launching _cmd.exe /c ver_ to get the Windows version (and uname for linux/mac). I want to confirm that is what is happening for you.

Yes, it is launching _cmd.exe /c ver_

[dalvarezperez]

I got infected with Gandcrab v5.2 while analyzing it named as: "cmd.exe"
But this behaviour will happen with any other threat.

[dalvarezperez]

This security breach was silently fixed. It is not in release notes: https://ghidra-sre.org/releaseNotes.html#9_0_1

[ryanmkurtz]

Unfortunately this issue was not able to be fixed for 9.0.1. Are you sure you are testing it in exactly the same manner as when you reported it?

[dalvarezperez]

You are right. It is not fixed yet.

[ryanmkurtz]

cmd.exe is also launched every time you call getwindowsversion() from the interpreter.

[dalvarezperez]

It is possible to set the JAVA working directory avoiding most of these situations instead of fixing one by one. I suggest to add the following code into "support\launch.bat" :
cd /d %~dp0/../
But well, an analogous command will be necessary for Linux/Mac into the file "support\launch.sh"

[0x6d696368]

I would say this is an issue in Jython. More specifically this line: https://github.com/jythontools/jython/blob/master/src/org/python/core/PySystemState.java#L1786

I would open an issue there and have it fixed upstream.

---

However, Ghidra has the same issue when opening manuals, see: https://github.com/NationalSecurityAgency/ghidra/blob/49c2010b63b56c8f20845f3970fedd95d003b1e9/Ghidra/Features/Base/src/main/java/ghidra/util/ManualViewerCommandWrappedOption.java#L121

I would use %COMSPEC% which is the Windows env var for the comandline interpreter binary.

Linux should be OK as there binaries that are not in the PATH env var can only be executed by prefixing them with ./. So uname will not run a local uname. To run a local uname bin in the CWD you'd have to run ./uname... as Unix has identified this problem of local binaries shadowing global ones early on and recognized the threat this poses.

[NicoleG25]

@ryanmkurtz was this issue ever addressed ?
If so could you point me to the fixing commit ?
Please note that this issue was assigned CVE-2019-17664.
Thanks in advance !

[ryanmkurtz]

No, it is not fixed. It's more of an issue with Jython...it should be fixed in that library. As far as I know, Jython is unaware of the issue.

[NicoleG25]

@jeff5 Could you take a look/have someone take a look at this ?
Thanks in advance :)

@ryanmkurtz was this issue ever addressed ?
If so could you point me to the fixing commit ?
Please note that this issue was assigned CVE-2019-17664.
Thanks in advance !

[jeff5]

Happy to take a look You just missed v2.7.2, sorry. I raised https://bugs.jython.org/issue2882 .

Almost certainly, the right answer is to use COMSPEC as @0x6d696368 suggests.

The standard library subprocess.py in CPython falls back to cmd.exe if COMSPEC is not defined, but Jython's subprocess.py on;y uses a value ultimately defined in enum OS, cmd.exe . Given the experience here, the fallback may be undesirable.

[NicoleG25]

Thank you Jeff !