Description
The various run modes of the Ghidra client application on Linux and macOS are typically launched via small shell scripts that pass both fixed and user-provided command line arguments to a common launch.sh helper script. The final step of launch.sh is to launch the Ghidra client java application, passing along any user-provided command line arguments. The launch.sh script in Ghidra < 10.2.3 uses the eval shell command to accomplish this, which executes the final command line as if the user typed it directly into the terminal.
If the user-provided command line arguments contain shell commands, they will get executed by launch.sh as the Ghidra client application starts up. Ghidra 10.2.3 and later avoids all use of the eval command in launch.sh.
Impact
The Ghidra client application's typical use case assumes a trusted user is initiating the launch, passing in trusted input. In this supported use case, the CVE is not relevant because the user has full control over their own terminal and what input they pass to the Ghidra client application. If they wish to execute malicious commands on their local machine, there are more direct ways to do it (i.e., type it directly onto the command line).
The CVE becomes more relevant when a user has set up the Ghidra client application to run as a service on a remote machine, allowing untrusted input to be passed directly from an untrusted user into a Ghidra command line argument. This could result in an untrusted user executing arbitrary shell commands on the same machine that the Ghidra client application runs on. While the Ghidra client application was not designed to support this use case, there are no technical restrictions on using it this way.
NOTE: The multi-user Ghidra server is not launched with launch.sh, nor does it use the eval shell command, so it is not affected by the CVE. The CVE applies specifically to launching instances of the Ghidra client application on macOS and Linux.
Recommendation
If you are only running the Ghidra client application locally where the user launching Ghidra is trusted, no action is required.
If you have configured the Ghidra client application to run as a service on a remote machine, it is best practice to sanitize all untrusted user input as early as possible. It is also recommended to upgrade to Ghidra 10.2.3 or later to prevent untrusted malicious input from being executed, should sanitization efforts fail.
NOTE: Ghidra was designed to be able to execute user-proved "GhidraScripts" written in either Java or Python. By design, the GhidraScripts contain arbitrary Java or Python code. If you are running the Ghidra client application as a service where you are accepting input from an untrusted user, special attention should be given to how you will securely handle the execution of user-provided GhidraScripts.
Upgrading Existing Installation
References
The details of the vulnerability can be found here:
For more information
If you have any additional questions, comments, or concerns about this advisory and how it impacts Ghidra, please do not hesitate to open an issue in the Ghidra project's discussions or issues.
attilaszia Analyst
Description
The various run modes of the Ghidra client application on Linux and macOS are typically launched via small shell scripts that pass both fixed and user-provided command line arguments to a common
launch.shhelper script. The final step oflaunch.shis to launch the Ghidra client java application, passing along any user-provided command line arguments. Thelaunch.shscript in Ghidra < 10.2.3 uses theevalshell command to accomplish this, which executes the final command line as if the user typed it directly into the terminal.If the user-provided command line arguments contain shell commands, they will get executed by
launch.shas the Ghidra client application starts up. Ghidra 10.2.3 and later avoids all use of theevalcommand inlaunch.sh.Impact
The Ghidra client application's typical use case assumes a trusted user is initiating the launch, passing in trusted input. In this supported use case, the CVE is not relevant because the user has full control over their own terminal and what input they pass to the Ghidra client application. If they wish to execute malicious commands on their local machine, there are more direct ways to do it (i.e., type it directly onto the command line).
The CVE becomes more relevant when a user has set up the Ghidra client application to run as a service on a remote machine, allowing untrusted input to be passed directly from an untrusted user into a Ghidra command line argument. This could result in an untrusted user executing arbitrary shell commands on the same machine that the Ghidra client application runs on. While the Ghidra client application was not designed to support this use case, there are no technical restrictions on using it this way.
NOTE: The multi-user Ghidra server is not launched with
launch.sh, nor does it use theevalshell command, so it is not affected by the CVE. The CVE applies specifically to launching instances of the Ghidra client application on macOS and Linux.Recommendation
If you are only running the Ghidra client application locally where the user launching Ghidra is trusted, no action is required.
If you have configured the Ghidra client application to run as a service on a remote machine, it is best practice to sanitize all untrusted user input as early as possible. It is also recommended to upgrade to Ghidra 10.2.3 or later to prevent untrusted malicious input from being executed, should sanitization efforts fail.
NOTE: Ghidra was designed to be able to execute user-proved "GhidraScripts" written in either Java or Python. By design, the GhidraScripts contain arbitrary Java or Python code. If you are running the Ghidra client application as a service where you are accepting input from an untrusted user, special attention should be given to how you will securely handle the execution of user-provided GhidraScripts.
Upgrading Existing Installation
References
The details of the vulnerability can be found here:
For more information
If you have any additional questions, comments, or concerns about this advisory and how it impacts Ghidra, please do not hesitate to open an issue in the Ghidra project's discussions or issues.