Source: git Version: 1:2.43.0-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team <t...@security.debian.org>
Hi, The following vulnerabilities were published for git. CVE-2024-32002[0]: | Git is a revision control system. Prior to versions 2.45.1, 2.44.1, | 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with | submodules can be crafted in a way that exploits a bug in Git | whereby it can be fooled into writing files not into the submodule's | worktree but into a `.git/` directory. This allows writing a hook | that will be executed while the clone operation is still running, | giving the user no opportunity to inspect the code that is being | executed. The problem has been patched in versions 2.45.1, 2.44.1, | 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support | is disabled in Git (e.g. via `git config --global core.symlinks | false`), the described attack won't work. As always, it is best to | avoid cloning repositories from untrusted sources. CVE-2024-32004[1]: | Git is a revision control system. Prior to versions 2.45.1, 2.44.1, | 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, an attacker can prepare | a local repository in such a way that, when cloned, will execute | arbitrary code during the operation. The problem has been patched in | versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. | As a workaround, avoid cloning repositories from untrusted sources. CVE-2024-32020[2]: | Git is a revision control system. Prior to versions 2.45.1, 2.44.1, | 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up | hardlinking files into the target repository's object database when | source and target repository reside on the same disk. If the source | repository is owned by a different user, then those hardlinked files | may be rewritten at any point in time by the untrusted user. Cloning | local repositories will cause Git to either copy or hardlink files | of the source repository into the target repository. This | significantly speeds up such local clones compared to doing a | "proper" clone and saves both disk space and compute time. When | cloning a repository located on the same disk that is owned by a | different user than the current user we also end up creating such | hardlinks. These files will continue to be owned and controlled by | the potentially-untrusted user and can be rewritten by them at will | in the future. The problem has been patched in versions 2.45.1, | 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. CVE-2024-32021[3]: | Git is a revision control system. Prior to versions 2.45.1, 2.44.1, | 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local | source repository that contains symlinks via the filesystem, Git may | create hardlinks to arbitrary user-readable files on the same | filesystem as the target repository in the `objects/` directory. | Cloning a local repository over the filesystem may creating | hardlinks to arbitrary user-owned files on the same filesystem in | the target Git repository's `objects/` directory. When cloning a | repository over the filesystem (without explicitly specifying the | `file://` protocol or `--no-local`), the optimizations for local | cloning will be used, which include attempting to hard link the | object files instead of copying them. While the code includes checks | against symbolic links in the source repository, which were added | during the fix for CVE-2022-39253, these checks can still be raced | because the hard link operation ultimately follows symlinks. If the | object on the filesystem appears as a file during the check, and | then a symlink during the operation, this will allow the adversary | to bypass the check and create hardlinks in the destination objects | directory to arbitrary, user-readable files. The problem has been | patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, | and 2.39.4. CVE-2024-32465[4]: | Git is a revision control system. The Git project recommends to | avoid working in untrusted repositories, and instead to clone it | first with `git clone --no-local` to obtain a clean copy. Git has | specific protections to make that a safe operation even with an | untrusted source repository, but vulnerabilities allow those | protections to be bypassed. In the context of cloning local | repositories owned by other users, this vulnerability has been | covered in CVE-2024-32004. But there are circumstances where the | fixes for CVE-2024-32004 are not enough: For example, when obtaining | a `.zip` file containing a full copy of a Git repository, it should | not be trusted by default to be safe, as e.g. hooks could be | configured to run within the context of that repository. The problem | has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, | 2.40.2, and 2.39.4. As a workaround, avoid using Git in repositories | that have been obtained via archives from untrusted sources. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-32002 https://www.cve.org/CVERecord?id=CVE-2024-32002 [1] https://security-tracker.debian.org/tracker/CVE-2024-32004 https://www.cve.org/CVERecord?id=CVE-2024-32004 [2] https://security-tracker.debian.org/tracker/CVE-2024-32020 https://www.cve.org/CVERecord?id=CVE-2024-32020 [3] https://security-tracker.debian.org/tracker/CVE-2024-32021 https://www.cve.org/CVERecord?id=CVE-2024-32021 [4] https://security-tracker.debian.org/tracker/CVE-2024-32465 https://www.cve.org/CVERecord?id=CVE-2024-32465 Please adjust the affected versions in the BTS as needed. Regards, Salvatore