git: CVE-2024-32002 CVE-2024-32004 CVE-2024-32020 CVE-2024-32021 CVE-2024-32465

Debian Bug report logs - #1071160
git: CVE-2024-32002 CVE-2024-32004 CVE-2024-32020 CVE-2024-32021 CVE-2024-32465

version graph

Reported by: Salvatore Bonaccorso <carnil@debian.org>

Date: Wed, 15 May 2024 09:48:01 UTC

Severity: grave

Tags: security, upstream

Found in version git/1:2.43.0-1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, carnil@debian.org, team@security.debian.org, Jonathan Nieder <jrnieder@gmail.com>:
Bug#1071160; Package src:git. (Wed, 15 May 2024 09:48:03 GMT) (full text, mbox, link).


Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
New Bug report received and forwarded. Copy sent to carnil@debian.org, team@security.debian.org, Jonathan Nieder <jrnieder@gmail.com>. (Wed, 15 May 2024 09:48:03 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: git: CVE-2024-32002 CVE-2024-32004 CVE-2024-32020 CVE-2024-32021 CVE-2024-32465
Date: Wed, 15 May 2024 11:45:35 +0200
Source: git
Version: 1:2.43.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: carnil@debian.org, Debian Security Team <team@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



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed May 15 11:55:53 2024; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.