Attack Chain

1. Attacker creates a malicious repository.
2. The repository contains a symbolic link named .gitmodules that points to a file outside the repository’s worktree controlled by the attacker.
3. A user clones the malicious repository using a vulnerable version of gitoxide or gix.
4. The application calls Repository::submodules() to enumerate submodules.
5. std::fs::read() follows the symlink when reading the .gitmodules file.
6. gitoxide parses the contents of the attacker-controlled file as submodule configuration.
7. The parsed submodule data, including attacker-controlled name, path, and URL values, is exposed through the Submodule objects.
8. Downstream git workflows use the injected metadata to clone, fetch, update, or enforce policies, potentially leading to unintended or malicious actions.

Impact

The vulnerability allows for the injection of out-of-repository bytes into the result of Repository::submodules(). This means attackers can mislead callers about submodule metadata, such as name, path, and URL. Any downstream workflow that uses these values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data. While the report doesn’t claim direct command execution, it highlights the risk of metadata injection across the repository boundary, potentially leading to security breaches or data compromise.

Recommendation

Prioritize the following actions to mitigate this vulnerability:

• Upgrade to gitoxide version > 0.52.0 or gix version >= 0.83.0 to incorporate the fix that prevents following symlinks for .gitmodules (Affected Products).
• Implement checks to reject symlinked .gitmodules files when loading from the worktree using symlink_metadata() or lstat style checks (Reference: GHSA-pg4w-g64p-qwhj).
• Canonicalize the target path of .gitmodules and verify that it resides within the repository worktree before reading (Reference: GHSA-pg4w-g64p-qwhj).
• For security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path (Reference: GHSA-pg4w-g64p-qwhj).

Attack Chain

1. An attacker crafts a malicious Git packfile containing either truncated delta data or an entry with an extremely large decompressed_size.
2. A user or automated system initiates a git clone or git fetch operation from a repository controlled by the attacker.
3. The gix-pack library attempts to parse the crafted packfile.
4. If the packfile contains truncated delta data, the apply() function in gix-pack/src/data/delta.rs attempts to access array indices beyond the bounds of the data buffer, leading to a panic. Alternatively, the parse_header_info() function in gix-pack/src/data/entry/decode.rs can also panic due to unchecked indexing.
5. If the packfile contains an entry with an extremely large decompressed_size, the library attempts to allocate a large buffer using Vec::with_capacity(size as usize) in bytes_to_entries.rs or Vec::resize() in resolve.rs.
6. The allocation of the excessively large buffer exhausts available memory, triggering an out-of-memory (OOM) condition.
7. The operating system terminates the process to prevent further memory exhaustion.
8. The application using gix-pack crashes, resulting in a denial-of-service.

Impact

Successful exploitation of these vulnerabilities leads to a denial-of-service (DoS) condition. For the panic vulnerability, a small amount of crafted data causes an immediate process abort. For the OOM vulnerability, a single crafted pack entry header causes the process to attempt a multi-terabyte allocation, leading to process termination by the operating system. This can affect various applications and systems, including the gix CLI, applications using the gix crate, and CI/CD systems, potentially disrupting software development workflows. The OOM vector represents a severe risk, as it is a single-packet process kill with no recovery.

Recommendation

• Upgrade to a patched version of gix-pack when available.
• Implement input validation on packfile data before processing to mitigate the OOM vulnerability. Specifically, implement a configurable maximum object size and validate claimed sizes against it before allocation, as suggested in the advisory.
• Monitor for process crashes or OOM events related to applications using gix-pack. Deploy the Sigma rule Detect Gix-Pack Uncapped Memory Allocation to identify potential OOM attacks.
• Consider blocking or filtering network traffic from untrusted Git repositories to prevent malicious packfiles from reaching vulnerable systems.

Attack Chain

1. An attacker creates a repository with a benign .gitmodules file, containing no update key.
2. A victim clones the attacker’s repository and runs git submodule init, which populates the .git/config file with submodule information (URL, active status), but not the update key.
3. The attacker pushes a new commit to the repository, adding a malicious update = !<command> line to the .gitmodules file (e.g., update = !touch /tmp/pwned).
4. The victim runs git pull to update their local repository, incorporating the attacker’s modified .gitmodules file. The .git/config file remains unchanged.
5. A gitoxide-based application calls Submodule::update() to determine the submodule update strategy.
6. The vulnerable gix_submodule::File::update function is called, which incorrectly validates the source of the update command.
7. The function checks that a submodule section with the same name exists in a non-.gitmodules source, but does not verify if the update value comes from that section, bypassing the intended security guard.
8. The attacker-controlled shell command from the .gitmodules file is executed, leading to arbitrary command execution.

Impact

The vulnerability allows an attacker to execute arbitrary commands on a system running gitoxide-based applications that utilize submodules. This could lead to complete system compromise, data exfiltration, or denial of service. Any tool, IDE plugin, or CI integration building submodule-update functionality on top of gix within the affected version range inherits this vulnerability. Successful exploitation depends on the vulnerable application’s trust in the output of Submodule::update() which determines the update strategy.

Recommendation

• Upgrade to gix version 0.83.0 or later to patch the vulnerability (https://github.com/advisories/GHSA-f26g-jm89-4g65).
• Implement additional validation and sanitization of submodule configurations, especially when handling Update::Command(_) from Submodule::update(), to prevent unintended command execution.
• Deploy the Sigma rule below to detect potential exploitation attempts by monitoring for the execution of unexpected commands based on submodule configuration.