malicious URLs may cause Git to present stored credentials to the wrong server

   peff published GHSA-qm7j-c969-7j4q Apr 14, 2020

   Severity
           high

   Packages
           Git

   Affected versions
           <= 2.17.3, 2.18.2, 2.19.3, 2.20.2, 2.21.1, 2.22.2, 2.23.1, 2.24.1,
           2.25.2, 2.26.0

   Patched versions
           2.17.4, 2.18.3, 2.19.4, 2.20.3, 2.21.2, 2.22.3, 2.23.2, 2.24.2,
           2.25.3, 2.26.1

   CVE identifier
           CVE-2020-5260

  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 contain an encoded newline
   can inject unintended values into the credential helper protocol stream,
   causing the credential helper to retrieve the password for one server
   (e.g., good.example.com) for an HTTP request being made to another server
   (e.g., evil.example.com), resulting in credentials for the former being
   sent to the latter. There are no restrictions on the relationship between
   the two, meaning that an attacker can craft a URL that will present stored
   credentials for any host to a host of their choosing.

   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.

  Patches

   The problem has been patched in the versions published on April 14th,
   2020, going back to v2.17.x. Anyone wishing to backport the change further
   can do so by applying commit 9a6bbee (the full release includes extra
   checks for git fsck, but that commit is sufficient to protect clients
   against the vulnerability).

  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 for
       the presence of encoded newlines (%0a) or evidence of
       credential-protocol injections (e.g., host=github.com)

     * avoid using submodules with untrusted repositories (don't use 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

  Credits

   This vulnerability was found by Felix Wilhelm of Google Project Zero and
   fixed by Jeff King of GitHub.

  References

     * release announcement
     * commits introducing fix

   Visible links
   . https://github.com/git/git/security/advisories/GHSA-qm7j-c969-7j4q#start-of-content
   . https://github.com/git/git/commit/9a6bbee8006c24b46a85d29e7b38cfa79e9ab21b
   . https://lore.kernel.org/git/xmqqy2qy7xn8.fsf@gitster.c.googlers.com/
   . https://github.com/git/git/compare/v2.17.3...v2.17.4