Impact
Git uses external "credential helper" programs to store and retrieve passwords or other credentials from secure storage provided by the operating system. Specially-crafted URLs that are considered illegal as of the recently published Git versions can cause Git to send a "blank" pattern to helpers, missing hostname and protocol fields. Many helpers will interpret this as matching any URL, and will return some unspecified stored password, leaking the password to an attacker's server.
The vulnerability can be triggered by feeding a malicious URL to git clone
. However, the affected URLs look rather suspicious; the likely vector would be through systems which automatically clone URLs not visible to the user, such as Git submodules, or package systems built around Git.
This bug is similar to the one mentioned in CVE-2020-5260. The fix for that bug still left the door open for an exploit where some credential is leaked (but the attacker cannot control which one).
The root of the problem is in Git itself, which should not be feeding blank input to helpers. However, the ability to exploit the vulnerability in practice depends on which helpers are in use.
Credential helpers which are known to trigger the vulnerability:
- Git's
store
helper
- Git's
cache
helper
- the
osxkeychain
helper that ships in Git's contrib
directory
Credential helpers which are known to be safe even with vulnerable versions of Git:
- Git Credential Manager for Windows
Any helper not in this list should be assumed to trigger the vulnerability.
Patches
The problem has been patched in the versions published on April 20th, 2020, going back to v2.17.x.
Workarounds
The most complete workaround is to disable credential helpers altogether:
git config --unset credential.helper
git config --global --unset credential.helper
git config --system --unset credential.helper
An alternative is to avoid malicious URLs:
-
Examine the hostname and username portion of URLs fed to git clone
or git fetch
for the presence of encoded newlines (%0A
) or syntactic oddities (e.g., http:///host
with three slashes).
-
Avoid using submodules with untrusted repositories (don't use git clone --recurse-submodules
; use git submodule update
only after examining the URLs found in .gitmodules
).
-
Avoid tools which may run git clone
on untrusted URLs under the hood.
-
Avoid using the credential helper by only cloning publicly available repositories.
Credits
Credit for finding the vulnerability goes to Carlo Arenas.
References
Impact
Git uses external "credential helper" programs to store and retrieve passwords or other credentials from secure storage provided by the operating system. Specially-crafted URLs that are considered illegal as of the recently published Git versions can cause Git to send a "blank" pattern to helpers, missing hostname and protocol fields. Many helpers will interpret this as matching any URL, and will return some unspecified stored password, leaking the password to an attacker's server.
The vulnerability can be triggered by feeding a malicious URL to
git clone
. However, the affected URLs look rather suspicious; the likely vector would be through systems which automatically clone URLs not visible to the user, such as Git submodules, or package systems built around Git.This bug is similar to the one mentioned in CVE-2020-5260. The fix for that bug still left the door open for an exploit where some credential is leaked (but the attacker cannot control which one).
The root of the problem is in Git itself, which should not be feeding blank input to helpers. However, the ability to exploit the vulnerability in practice depends on which helpers are in use.
Credential helpers which are known to trigger the vulnerability:
store
helpercache
helperosxkeychain
helper that ships in Git'scontrib
directoryCredential helpers which are known to be safe even with vulnerable versions of Git:
Any helper not in this list should be assumed to trigger the vulnerability.
Patches
The problem has been patched in the versions published on April 20th, 2020, going back to v2.17.x.
Workarounds
The most complete workaround is to disable credential helpers altogether:
An alternative is to avoid malicious URLs:
Examine the hostname and username portion of URLs fed to
git clone
orgit fetch
for the presence of encoded newlines (%0A
) or syntactic oddities (e.g.,http:///host
with three slashes).Avoid using submodules with untrusted repositories (don't use
git clone --recurse-submodules
; usegit submodule update
only after examining the URLs found in.gitmodules
).Avoid tools which may run
git clone
on untrusted URLs under the hood.Avoid using the credential helper by only cloning publicly available repositories.
Credits
Credit for finding the vulnerability goes to Carlo Arenas.
References
release announcement
commit introducing fix