The GitHub Security Lab audits open source projects for security vulnerabilities and helps maintainers fix them. Recently, we passed the milestone of 500 CVEs disclosed. Let’s take a trip down memory lane with a review of some noteworthy CVEs!
Today, the Git project released new versions to address a pair of security vulnerabilities (CVE-2022-39253, and CVE-2022-39260) that affect versions 2.38 and older. These affect Git’s
--local clone optimization and
git shell‘s interactive command mode.
The first set of updates addresses an issue where Git’s
--local clone mechanism can be used to dereference symbolic links present in a repository’s
$GIT_DIR/objects directory in order to provide hardlinks or copies of the symbolic link’s target rather than the link itself.
This vulnerability can be used to break security boundaries, by injecting sensitive content into a malicious Docker container, for example. This attack relies on the existence of a symbolic link inside of a repository’s
$GIT_DIR/objects directory, meaning that you must either clone a malicious repository locally, or clone a malicious repository packaged as a local submodule inside of another repository.
To address this vulnerability, Git will now refuse to clone repositories via the
--local clone optimization if there are symbolic links present within the
objects directory. Git has also changed the default value of
protocol.file.allow to “user”, meaning that
file:// clones are considered unsafe by default1.
Credit for finding this vulnerability goes to Cory Snider of Mirantis.
The other update addresses an integer overflow bug in
git shell via the
split_cmdline() function. This vulnerability can only be exploited by victims who have
git shell exposed as a login shell, and have enabled its interactive mode by creating the directory
This integer overflow can result in arbitrary heap writes, which may result in arbitrary code execution.
Credit for finding the vulnerability goes to Kevin Backhouse of the GitHub Security Lab.
The most effective way to protect against these vulnerabilities is to upgrade to Git 2.38.1. If you can’t update immediately, reduce your risk by taking the following steps:
- Avoid running
git shell, or disable its interactive mode with
rm -fr $HOME/git-shell-commandsif doing so is impractical.
- Avoid running
--recurse-submodulesagainst untrusted repositories.
If submodules are required by your workflow and you cannot upgrade, clone embedded submodules only after inspecting their contents to ensure they do not contain symbolic links in their `$GIT_DIR/objects` directory.
Crucially, clone submodules iteratively rather than recursively by running `git submodule update` at each layer of your repository’s submodule chain.
In order to protect users against these attacks, GitHub has taken proactive steps. Specifically, we:
- Scheduled a GitHub Desktop release for later today, October 18, that prevents the exploitation of this vulnerability.
Scheduled updates to GitHub Codespaces2 and GitHub Actions to upgrade their versions of Git.
GitHub’s repository storage backend does not recursively clone submodules, so is not affected by CVE-2022-39253. GitHub also does not run `git shell` and is thus not affected by CVE-2022-39260 either. GitHub Pages already prevents out-of-repository symbolic links, as well as non-
https://submodule URLs, and is thus not affected by CVE-2022-39253.
- In addition to the attack described by CVE-2022-39253, permitting a repository to clone arbitrary repositories on your filesystem via submodules is an unsafe practice. This can be exploited to clone repositories containing sensitive content from well-known locations (such as “/home/username/.git”, which is often used to store sensitive information such as SSH keys) ↩
- By default, GitHub Codespaces does not recursively clone submodules when initializing a new Codespace. ↩