=================================================================== CERT-Renater Note d'Information No. 2022/VULN390 _____________________________________________________________________ DATE : 19/10/2022 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Git versions prior to 2.30.6, 2.31.5, 2.32.4, 2.33.5, 2.34.5, 2.35.5, 2.36.3, 2.37.4, 2.38.1. ====================================================================https://github.com/git/git/security/advisories/GHSA-rjr6-wcq6-83p6 https://github.com/git/git/security/advisories/GHSA-3wp6-j8xr-qw85 https://github.blog/2022-10-18-git-security-vulnerabilities-announced/ _____________________________________________________________________ Heap overflow in `git shell` leading to RCE High ttaylorr published GHSA-rjr6-wcq6-83p6 Package No package listed Affected versions <= v2.30.5, v2.31.4, v2.32.3, v2.33.4, v2.34.4, v2.35.4, v2.36.2, v2.37.3, v2.38.0 Patched versions > = v2.30.6, v2.31.5, v2.32.4, v2.33.5, v2.34.5, v2.35.5, v2.36.3, v2.37.4, v2.38.1 Description Impact git shell is a restricted login shell that can be used to implement Git's push/pull functionality via SSH. Typically git shell only allows executing receive-pack, upload-pack, or upload-archive, each followed by an arbitrary specified by the caller: If $HOME/git-shell-commands exists and is a directory, however, then any script in that directory can be executed by name with user-provided arguments. Before executing commands, git shell splits the given string into an array with split_cmdline(). This function improperly uses an int to represent the number of entries (argc) in the argv array, allowing a malicious actor to intentionally overflow the return value, leading to arbitrary heap writes. Because the resulting argv array is then passed to execv(), it is possible to leverage this attack to gain remote code execution on a victim machine. Note that a victim must first allow access to git shell as a login shell, and allow interactive mode by having the $HOME/git-shell-commands directory present in order to be vulnerable to this attack. Patches The problem has been patched in the versions published on 2022-10-18, going back to v2.30.x. Workarounds The most complete workaround is upgrading to the most recent patched version published. If doing so is impractical, then disabling git shell access via remote logins is encouraged in the short-term. If git shell cannot be disabled as a login shell, then disabling its interactive mode by removing the git-shell-commands directory is encouraged. Credit Credit for finding the vulnerability goes to Kevin Backhouse of the GitHub Security Lab. Severity High CVE ID CVE-2022-39260 Weaknesses No CWEs Credits @kevinbackhouse kevinbackhouse _____________________________________________________________________ Local clone optimization dereferences symbolic links by default Moderate ttaylorr published GHSA-3wp6-j8xr-qw85 Package No package listed Affected versions <= v2.30.5, v2.31.4, v2.32.3, v2.33.4, v2.34.4, v2.35.4, v2.36.2, v2.37.3, v2.38.0 Patched versions > = v2.30.6, v2.31.5, v2.32.4, v2.33.5, v2.34.5, v2.35.5, v2.36.3, v2.37.4, v2.38.1 Description Impact When performing a local clone (where the source and target of the clone are on the same volume), Git copies the contents of the source's $GIT_DIR/objects directory into the destination by either creating hardlinks to the source contents, or copying them (if hardlinks are disabled via --no-hardlinks). Prior to the patched versions of Git published today, Git's implementation of its local clone behavior caused it to create hardlinks (or copies) of the dereferenced target of any symbolic links present in the source repository's $GIT_DIR/objects directory. A malicious actor could convince a victim to clone a repository with a symbolic link pointing at sensitive information on the victim's machine. This can be done either by having the victim clone a malicious repository on the same machine, or having them clone a malicious repository embedded as a bare repository via a submodule from any source, provided they clone with the --recurse-submodules option. Git does not create symbolic links in the $GIT_DIR/objects directory. Patches The problem has been patched in the versions published on 2022-10-18, going back to v2.30.x. Workarounds The most complete workaround is upgrading to the most recent patched version published. If doing so is impractical, then there are a couple of short-term workarounds. Avoid cloning untrusted repositories using the --local optimization when on a shared machine, by passing the --no-local option to git clone or cloning from a URL that uses the file:// scheme. Avoid cloning repositories from untrusted sources with --recurse-submodules. Or, run git config --global protocol.file.allow user. Credit Credit for finding the vulnerability goes to Cory Snider of Mirantis. Wenxiang Qian of Tencent Blade Team reported the symlink copy vulnerability in the docker build command. Bjorn Neergaard of Mirantis discovered that Podman is also vulnerable. Severity Moderate CVE ID CVE-2022-39253 Weaknesses No CWEs _____________________________________________________________________ Git security vulnerabilities announced Upgrade your local installation of Git, especially when cloning with --recurse-submodules from untrusted repositories, or if you use git shell interactive mode. Git security vulnerabilities announced Author Taylor BlauTaylor Blau October 18, 2022 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. CVE-2022-39253 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. [source] CVE-2022-39260 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 $HOME/git-shell-commands. 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. [source] Upgrade to the latest Git version 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-commands if doing so is impractical. Avoid running git clone with --recurse-submodules against 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. Download Git 2.38.1 Notes 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. ========================================================+ CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =======================================================