Remote command execution In simple-git
Description
simple-git Affected by Command Execution via Option-Parsing Bypass
Summary
simple-git enables running native Git commands from JavaScript. Some commands accept options that allow executing another command; because this is very dangerous, execution is denied unless the user explicitly allows it. This vulnerability allows a malicious actor who can control the options to execute other commands even in a “safe” state where the user has not explicitly allowed them. The vulnerability was introduced by an incorrect patch for CVE-2022-25860. It is likely to affect all versions prior to and including 3.28.0.
Detail
This vulnerability was introduced by an incorrect patch for CVE-2022-25860.
It was reproduced in the following environment:
WSL Docker node: v22.19.0 git: git version 2.39.5 simple-git: 3.28.0
The issue was not reproduced on Windows 11.
The -u option, like --upload-pack, allows a command to be executed.
Currently, the -u and --upload-pack options are blocked in the file simple-git/src/lib/plugins/block-unsafe-operations-plugin.ts.
function preventUploadPack(arg: string, method: string) { if (/^\s*--(upload|receive)-pack/.test(arg)) { throw new GitPluginError( undefined, 'unsafe', `Use of --upload-pack or --receive-pack is not permitted without enabling allowUnsafePack` ); }...
However, the problem is that command option parsing is quite flexible.
By brute forcing, I found various options that bypass the -u check.
[ '--u', '--u', '-4u', '-6u', '-lu', '-nu', '-qu', '-su', '-vu' ]
All of the above are three-character options that allow command execution. They enable execution even when allowUnsafePack is explicitly set to false.
The depressing fact is that the options I found are probably only a tiny fraction of all possible option formats that enable command execution. In addition to the -u option, there is also the --upload-pack option and others, and some of the options I found can probably be extended to arbitrary length. Considering this, the number of option variants that enable command execution is probably infinite.
Therefore, I could not find an effective way to block all such cases. Personally, I think it is virtually impossible to block this vulnerability completely. To fully block it, one would have to faithfully emulate Git’s option parsing rules, and it’s doubtful whether that is feasible.
Just in case, I’ll share the brute-force code I used to find options that enable command execution.
const fs = require('fs'); const simpleGit = require('simple-git'); const TMP_DIR = './pwned/'; const ITER = 256; function cleanTmpDir() { if (fs.existsSync(TMP_DIR)) {...
PoC
The environment in which I succeeded is as follows. As long as the OS remains Linux, I suspect it will succeed reliably despite considerable variation in other factors.
WSL Docker node: v22.19.0 git: git version 2.39.5 simple-git: 3.28.0
Create any git repository inside the testrepo1 folder. A very simple repository with a single commit and a single file is fine.
Run the following:
const { simpleGit } = require('simple-git'); async function main() { const git = await simpleGit({ unsafe: { allowUnsafePack: false } }); await git.clone('./testrepo1', './testrepo2', [`-vu sh -c \"touch /tmp/pwned\"`]); } main();...
This PoC explicitly configures allowUnsafePack to false. Of course, the same vulnerability occurs even without this option. An error is the expected behavior.
Check /tmp to confirm that pwned has been created.
If it failed, try replacing -vu with a different option from the list.
Impact
This vulnerability is likely to affect all versions prior to and including 3.28.0. This is because it appears to be a continuation of the series of four vulnerabilities previously found in simple-git (CVE-2022-24433, CVE-2022-24066, CVE-2022-25912, CVE-2022-25860).
Mitigation
Update Impact
Minimal update. May introduce new vulnerabilities or breaking changes.
Ecosystem | Component | Affected version | Patched versions |
|---|---|---|---|
npm | 3.32.0 |
Aliases
References