8 CVE-2024-52308
The GitHub CLI version 2.6.1 and earlier are vulnerable to remote code execution through a malicious codespace SSH server when using `gh codespace ssh` or `gh codespace logs` commands. This has been patched in the cli v2.62.0.
Developers connect to remote codespaces through an SSH server running within the devcontainer, which is generally provided through the [default devcontainer image]( https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-... https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers#using-the-default-dev-container-configuration) . GitHub CLI [retrieves SSH connection details]( https://github.com/cli/cli/blob/30066b0042d0c5928d959e288144300cb28196c9/internal/codespaces/rpc/inv... https://github.com/cli/cli/blob/30066b0042d0c5928d959e288144300cb28196c9/internal/codespaces/rpc/invoker.go#L230-L244 ), such as remote username, which is used in [executing `ssh` commands]( https://github.com/cli/cli/blob/e356c69a6f0125cfaac782c35acf77314f18908d/pkg/cmd/codespace/ssh.go#L2... https://github.com/cli/cli/blob/e356c69a6f0125cfaac782c35acf77314f18908d/pkg/cmd/codespace/ssh.go#L263 ) for `gh codespace ssh` or `gh codespace logs` commands.
This exploit occurs when a malicious third-party devcontainer contains a modified SSH server that injects `ssh` arguments within the SSH connection details. `gh codespace ssh` and `gh codespace logs` commands could execute arbitrary code on the user's workstation if the remote username contains something like `-oProxyCommand="echo hacked" #`. The `-oProxyCommand` flag causes `ssh` to execute the provided command while `#` shell comment causes any other `ssh` arguments to be ignored.
In `2.62.0`, the remote username information is being validated before being used.
https://nvd.nist.gov/vuln/detail/CVE-2024-52308
Categories
CWE-77 : Improper Neutralization of Special Elements used in a Command ('Command Injection')
The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component. an attack-oriented phrase for this weakness. Note: often used when "OS command injection" (CWE-78) was intended. Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) If at all possible, use library calls rather than external processes to recreate the desired functionality. If possible, ensure that all external commands called from the program are statically created. Run time: Run time policy enforcement may be used in an allowlist fashion to prevent use of any non-sanctioned commands. Assign permissions that prevent the user from accessing/opening privileged files. injection of sed script syntax ("sed injection") API service using a large generative AI model allows direct prompt injection to leak hard-coded system prompts or execute other prompts. anti-spam product allows injection of SNMP commands into confiuration file image program allows injection of commands in "Magick Vector Graphics (MVG)" language. Python-based dependency management tool avoids OS command injection when generating Git commands but allows injection of optional arguments with input beginning with a dash (CWE-88), potentially allowing for code execution. Canonical example of OS command injection. CGI program does not neutralize "|" metacharacter when invoking a phonebook program. Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV. injection of sed script syntax ("sed injection") injection of sed script syntax ("sed injection")
References
security-advisories@github.com
CPE
| cpe |
start |
end |
| Configuration 1 |
| cpe:2.3:a:github:cli:*:*:*:*:*:*:*:* |
|
< 2.62.0 |
REMEDIATION
EXPLOITS
Exploit-db.com
| id |
description |
date |
|
| No known exploits |
POC Github
Other Nist (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
description |
severity |
| 136 |
LDAP Injection
An attacker manipulates or crafts an LDAP query for the purpose of undermining the security of the target. Some applications use user input to create LDAP queries that are processed by an LDAP server. For example, a user might provide their username during authentication and the username might be inserted in an LDAP query during the authentication process. An attacker could use this input to inject additional commands into an LDAP query that could disclose sensitive information. For example, entering a * in the aforementioned query might return information about all users on the system. This attack is very similar to an SQL injection attack in that it manipulates a query to gather additional information or coerce a particular return value. [Survey application] The attacker takes an inventory of the entry points of the application. [Determine user-controllable input susceptible to LDAP injection] For each user-controllable input that the attacker suspects is vulnerable to LDAP injection, attempt to inject characters that have special meaning in LDAP (such as a single quote character, etc.). The goal is to create a LDAP query with an invalid syntax [Try to exploit the LDAP injection vulnerability] After determining that a given input is vulnerable to LDAP Injection, hypothesize what the underlying query looks like. Possibly using a tool, iteratively try to add logic to the query to extract information from the LDAP, or to modify or delete information in the LDAP. |
High |
| 15 |
Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on. [Assess Target Runtime Environment] In situations where the runtime environment is not implicitly known, the attacker makes connections to the target system and tries to determine the system's runtime environment. Knowing the environment is vital to choosing the correct delimiters. [Survey the Application] The attacker surveys the target application, possibly as a valid and authenticated user [Attempt delimiters in inputs] The attacker systematically attempts variations of delimiters on known inputs, observing the application's response each time. [Use malicious command delimiters] The attacker uses combinations of payload and carefully placed command delimiters to attack the software. |
High |
| 183 |
IMAP/SMTP Command Injection
An adversary exploits weaknesses in input validation on web-mail servers to execute commands on the IMAP/SMTP server. Web-mail servers often sit between the Internet and the IMAP or SMTP mail server. User requests are received by the web-mail servers which then query the back-end mail server for the requested information and return this response to the user. In an IMAP/SMTP command injection attack, mail-server commands are embedded in parts of the request sent to the web-mail server. If the web-mail server fails to adequately sanitize these requests, these commands are then sent to the back-end mail server when it is queried by the web-mail server, where the commands are then executed. This attack can be especially dangerous since administrators may assume that the back-end server is protected against direct Internet access and therefore may not secure it adequately against the execution of malicious commands. [Identify Target Web-Mail Server] The adversary first identifies the web-mail server they wish to exploit. [Identify Vulnerable Parameters] Once the adversary has identified a web-mail server, they identify any vulnerable parameters by altering their values in requests. The adversary knows that the parameter is vulnerable if the web-mail server returns an error of any sort. Ideally, the adversary is looking for a descriptive error message. [Determine Level of Injection] After identifying all vulnerable parameters, the adversary determines what level of injection is possible. [Inject IMAP/SMTP Commands] The adversary manipulates the vulnerable parameters to inject an IMAP/SMTP command and execute it on the mail-server. |
Medium |
| 248 |
Command Injection
An adversary looking to execute a command of their choosing, injects new items into an existing command thus modifying interpretation away from what was intended. Commands in this context are often standalone strings that are interpreted by a downstream component and cause specific responses. This type of attack is possible when untrusted values are used to build these command strings. Weaknesses in input validation or command construction can enable the attack and lead to successful exploitation. |
High |
| 40 |
Manipulating Writeable Terminal Devices
This attack exploits terminal devices that allow themselves to be written to by other users. The attacker sends command strings to the target terminal device hoping that the target user will hit enter and thereby execute the malicious command with their privileges. The attacker can send the results (such as copying /etc/passwd) to a known directory and collect once the attack has succeeded. [Identify attacker-writable terminals] Determine if users TTYs are writable by the attacker. [Execute malicious commands] Using one or more vulnerable TTY, execute commands to achieve various impacts. |
Very High |
| 43 |
Exploiting Multiple Input Interpretation Layers
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop. [Determine application/system inputs where bypassing input validation is desired] The attacker first needs to determine all of the application's/system's inputs where input validation is being performed and where they want to bypass it. [Determine which character encodings are accepted by the application/system] The attacker then needs to provide various character encodings to the application/system and determine which ones are accepted. The attacker will need to observe the application's/system's response to the encoded data to determine whether the data was interpreted properly. [Combine multiple encodings accepted by the application.] The attacker now combines encodings accepted by the application. The attacker may combine different encodings or apply the same encoding multiple times. [Leverage ability to bypass input validation] Attacker leverages their ability to bypass input validation to gain unauthorized access to system. There are many attacks possible, and a few examples are mentioned here. |
High |
| 75 |
Manipulating Writeable Configuration Files
Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users. |
Very High |
| 76 |
Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible. [Fingerprinting of the operating system] In order to create a valid file injection, the attacker needs to know what the underlying OS is so that the proper file seperator is used. [Survey the Application to Identify User-controllable Inputs] The attacker surveys the target application to identify all user-controllable inputs, possibly as a valid and authenticated user [Vary inputs, looking for malicious results] Depending on whether the application being exploited is a remote or local one, the attacker crafts the appropriate malicious input containing the path of the targeted file or other file system control syntax to be passed to the application [Manipulate files accessible by the application] The attacker may steal information or directly manipulate files (delete, copy, flush, etc.) |
Very High |
Cybersecurity needs ?
Strengthen software security from the outset with our DevSecOps expertise
Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.
Discover this offer
