Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <c228aaed-cc97-b0b2-38ad-bc0eb3f3135e@gmx.de>
Date: Tue, 14 May 2024 20:41:51 +0200 (CEST)
From: Johannes Schindelin <Johannes.Schindelin@....de>
To: oss-security@...ts.openwall.com
cc: git-security@...glegroups.com, Junio C Hamano <gitster@...ox.com>, 
    Patrick Steinhardt <ps@....im>, Filip Hejsek <filip.hejsek@...il.com>, 
    Jeff King <peff@...f.net>
Subject: git: 5 vulnerabilities fixed

Team,

The Git project released new security bug-fix versions today, May 14th,
2024: v2.45.1, v2.44.1, v2.43.4, v2.42.2, v2.41.1, v2.40.2, and v2.39.4.

The addressed issues are:

 * CVE-2024-32002
 * (https://github.com/git/git/security/advisories/GHSA-8h77-4q3w-gfgv):

   Recursive clones on case-insensitive filesystems that support symbolic
   links are susceptible to case confusion that can be exploited to
   execute just-cloned code during the clone operation.

   This allows the attack where a recursive clone would first initialize a
   submodule, then replace its parent directory with a symbolic link into
   the `.git/` directory where the second stage of the recursive clone
   would then write e.g. hooks that would be immediately executed before
   the user has had a chance to inspect what is getting executed.

   Credit for finding the vulnerability goes to Filip Hejsek, credit for
   fixing it goes to Johannes Schindelin.

 * CVE-2024-32004
 * (https://github.com/git/git/security/advisories/GHSA-xfc6-vwr8-r389):

   Repositories can be configured to execute arbitrary code during local
   clones. To address this, the ownership checks introduced in v2.30.3
   are now extended to cover cloning local repositories.

   The most obvious attack vector is to prepare a local partial clone that
   is intentionally missing objects, override in its config what
   `upload-pack` executable use, and then talk another user on the same
   machine to clone that. This will run that configured `upload-pack`
   executable under using person's permissions.

   Credit for finding the vulnerability goes to Filip Hejsek, credit for
   fixing it goes to Johannes Schindelin.

 * CVE-2024-32020
 * (https://github.com/git/git/security/advisories/GHSA-5rfh-556j-fhgj):

   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.

   This vulnerability allows a bait-and-switch attack where individual
   objects are replaced in already-indexed pack file; Git will not verify
   that the object's contents match its recorded object ID in that case.

   Credit for finding and for fixing the vulnerability goes to Patrick
   Steinhardt.

 * CVE-2024-32021
 * (https://github.com/git/git/security/advisories/GHSA-mvxm-9j2h-qjx7):

   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.

   This allows the same attack vector that CVE-2022-39253 tried to
   prevent, by exploiting a time-of-check-time-of-use race.

   Credit for finding and for fixing the vulnerability goes to Patrick
   Steinhardt.

 * CVE-2024-32465
 * (https://github.com/git/git/security/advisories/GHSA-vm9j-46j9-qvq4):

   It is supposed to be safe to clone untrusted repositories, even those
   unpacked from zip archives or tarballs originating from untrusted
   sources, but Git can be tricked to run arbitrary code as part of the
   clone.

   The attack vectors are the same as for the CVEs mentioned above that
   involve local clones, but social-engineering is required to manipulate
   a user into unpacking a `.zip` file and running Git commands on the
   unpacked files.

   Credit for finding and for fixing the vulnerability goes to Jeff King.

Note: the defense-in-depth protection in these new Git versions causes a
regression when cloning repositories enabled with Git LFS. The clone will
fail with an error message. The remedy is to call `git lfs pull` in the
fresh clone.

Thanks,
Johannes

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.