Git-semver-tags, a utility for retrieving Git semver tags in reverse chronological order, has released version 8.0.0, marking a significant update from the previous stable version 7.0.1. The primary difference lies in the dependencies. Version 8.0.0 replaces the direct dependency on semver with @conventional-changelog/git-client, suggesting a shift towards leveraging the conventional-changelog ecosystem for Git interactions. It also updates meow to version ^13.0.0 from ^12.0.1, bringing in potential breaking changes or new features from that dependency. If you used semver methods on data retrived with git-semver-tags, it is now advised to use functions from @conventional-changelog/git-client. This update impacts developers using git-semver-tags directly, particularly concerning dependency management and potential API adjustments. The package size is slightly smaller in the new version (6400 unpackedSize vs 6606), but this is a marginal gain. For developers already integrated into the conventional-changelog workflow, this update could streamline their processes. Those relying on the specific behavior of older meow or semver versions should carefully assess the changes introduced by the updated dependencies before upgrading. The release date also indicates a considerable gap between the two versions, with 7.0.1 released in September 2023 and 8.0.0 in May 2024, so it is better to check the changelog.
All the vulnerabilities related to the version 8.0.0 of the package
@conventional-changelog/git-client has Argument Injection vulnerability
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.
@conventional-changelog/git-client@1.0.1 or earlierimport {
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();
/tmp/r2d2While 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.
Liran Tal