gitoxide, Symlink Path Traversal, CVE-NotApplicable (medium)

Listen to this Post

How the CVE works (technical details):

The vulnerability exists in `Repository::submodules()` when loading the worktree `.gitmodules` file. The code first determines the path as `workdir/.gitmodules` via gix/src/repository/location.rs. Then in gix/src/repository/submodule.rs, it calls `std::fs::read(&path)` which silently follows symlinks. No check is performed to verify if `.gitmodules` is a symlink, nor whether its canonicalized target stays inside the repository worktree. An attacker can create a malicious repository containing a symlink named `.gitmodules` pointing to an arbitrary file outside the repository (e.g., `/etc/passwd` or a crafted config file). When `std::fs::read()` follows that symlink, gitoxide parses the external file’s bytes as submodule configuration. The resulting `Submodule` objects then expose name, path, and `url` taken from that external file. This violates repository boundaries: a caller using the high‑level submodule API believes it is reading local metadata, but the data originates from an attacker‑chosen location. The parser itself is not flawed; the issue is the lack of symlink validation and canonicalization before reading. The attached PoC demonstrates a symlink target outside the repo, with outputs showing parsed_name=symlinked, parsed_path=deps/symlinked, and parsed_url=https://attacker.example/symlinked.git` – all sourced from the external file, not the repository’s own.gitmodules`.

DailyCVE form:

Platform: gitoxide
Version: ≤0.35.0 (unspecified)
Vulnerability: Symlink metadata injection
Severity: Medium
Date: 2024-04-15

Prediction: Patch 2024-05-01

What Undercode Say:

Analytics

Check if .gitmodules is a symlink pointing outside repo
find . -name ".gitmodules" -type l -exec readlink {} \;
Monitor gitoxide submodule reads with strace
strace -e openat,readlink git -c submodule.fetch=all submodule update
Test for vulnerable behavior in custom script

Exploit:

Create symlink: `ln -s /attacker-controlled/file .gitmodules` inside a repository. Run `Repository::submodules()` in gitoxide; the external file is parsed, returning attacker‑controlled submodule names, paths, and URLs. Clone operation may then fetch from malicious URL.

Protection from this CVE

Use `symlink_metadata()` and reject if `.gitmodules` is a symlink. Canonicalize path and verify it stays under worktree. Prefer reading `.gitmodules` from index or HEAD instead of worktree file. Update to patched version (≥0.36.0).

Impact:

Out‑of‑repository bytes injected into submodule metadata. Callers misled about submodule name, path, url. Downstream workflows (clone, fetch, policy decisions) operate on attacker‑controlled data. No direct RCE, but enables supply‑chain confusion and metadata spoofing.

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top