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.
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.
--local
optimization when on a shared machine, by passing the--no-local
option togit clone
or cloning from a URL that uses thefile://
scheme.--recurse-submodules
. Or, rungit 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.