In May 2024, a security flaw was found in gitoxide, which is a blazing-fast, pure Rust implementation of Git. This vulnerability, tracked as CVE-2024-35197, mainly affects Windows users and could let malicious repositories cause denial of service, spoof application output, or even write data to sensitive OS devices.
This post breaks down the problem, shows how it can be triggered, and explains why cloning untrusted repos on Windows using gitoxide is risky.
Legacy Device Names on Windows
On Windows, some names like CON, PRN, AUX, NUL, COM1 to COM9, and LPT1 to LPT9 are reserved for legacy device files. These aren’t regular files—they map directly to hardware or special OS features. For example, writing to CON writes to the console, and reading from NUL always gives you nothing.
Why is this an issue?
Normally, applications should block creating files or folders with such names. But gitoxide did not properly check for these in all situations, which can be dangerous if you're working with untrusted repositories.
What Can Go Wrong?
- Cloning repositories that contain refs or file paths named like CON or AUX will cause gitoxide to:
Try reading from or writing to these devices instead of regular files.
- Reading: May cause gitoxide to hang indefinitely (for example, reading from CON will wait forever for console input).
- Writing: Could send arbitrary data to the Windows device (such as popping up weird messages in the command prompt).
Let’s see what this looks like in practice
Suppose someone creates a malicious repo with a file named CON or a branch/ref named AUX.
# On linux/macOS: Create a repo with a suspect file, zip it, and share it
git init evil-repo
cd evil-repo
touch CON
git add CON
git commit -m "Evil device file"
Normally, Git on Windows prevents files with such names. But gitoxide didn’t.
Now, when someone clones this repo on Windows using gitoxide
gitoxide clone https://github.com/attacker/evil-repo.git
gitoxide will try to checkout the CON file.
- On Windows only: This causes the application to write to CON (the console), sending any data from the repo file directly to the user's terminal!
Example: Fake “Success” Message
Suppose the data in CON is something like All your files were updated successfully!\n.
When gitoxide runs, the user may see this message even if the clone failed—a fake system message, originating straight from the attacker’s repo.
Denial of Service: The clone or checkout command hangs, needs to be killed manually.
- User confusion/Trickery: Fake messages in your console from supposedly successful commands.
- Potential for more: Under rare conditions, writing to some other reserved files can affect attached devices or communicate with system hardware, though extra permissions or very specific circumstances are usually required.
You clone repositories from untrusted sources.
- Not affected: Linux, macOS, and other OS users. Also not impacted if you never use untrusted repos.
Mitigation
- Avoid cloning or checking out from untrusted repositories on Windows using gitoxide until patches are applied.
patches And Upstream Reference
The problem was reported and patched upstream:
- Security Advisory: GHSA-cp5v-j5qc-vvfm
- CVE-2024-35197 on cve.org
Latest versions of gitoxide (after May 2024) contain the fix, which now blocks such operations on Windows.
Conclusion
CVE-2024-35197 in gitoxide shows how even a pure-Rust, memory-safe implementation can run into classic OS traps—especially on Windows, with its weird device files. Always keep your tools updated, be cautious with unknown repositories, and watch for device name edge cases!
References:
- Original advisory
- gitoxide repository
- What are Windows device files? (docs)
- CVE record
Timeline
Published on: 05/23/2024 13:15:09 UTC
Last modified on: 06/04/2024 17:34:47 UTC