You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
Name: git
CVEs: CVE-2024-32002, CVE-2024-32004, CVE-2024-32020, CVE-2024-32021, CVE-2024-32465
CVSSs: 9.0, 8.1, 3.9, 3.9, 7.3
Action Needed: update to either v2.45.1, v2.44.1, v2.43.4
Summary:
CVE-2024-32002
(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 clonewould 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
(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 samemachine 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
(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
(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
(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 theunpacked files.
Credit for finding and for fixing the vulnerability goes to Jeff King.
refmap.gentoo: https://bugs.gentoo.org/931941
The text was updated successfully, but these errors were encountered: