Git security: Newline injection bug tricked version control system into leaking usernames and password

When credential helpers give attackers a helping hand

UPDATED The Git Project has patched a vulnerability in which the open source version control system could be duped into leaking users’ credentials to an attacker-controlled host.

Uncovered by Google Project Zero researcher Felix Wilhelm, the security flaw centers on the external ‘credential helper’ programs that are used by Git to store and retrieve passwords and other credentials from secure storage furnished by the operating system.

While the exfiltration of credentials marks this as a potentially high-impact vulnerability (CVE-2020-5260), it has yet to be assigned a CVSS score.

Injecting unintended values

Git is widely used by software developers to project-manage code in open source projects.

In a post on the Chromium blog, Wilhelm, senior information security engineer at Google Project Zero, outlined his discovery that attackers could use specially-crafted URLs containing an encoded newline to inject unintended values into the credential helper protocol stream.

The credential helper consequently retrieves the password from one server for an HTTP request issued to another host – which duly receives the credentials.

The CVE entry for this bug suggests that systems which automatically clone URLs that are invisible to the user – like Git submodules or Git-optimized package systems – are the most likely vectors.

Disclosure and patches

The newline injection vulnerability was flagged to the Git Project on March 9 and was due for public disclosure on June 7, in line with Google’s 90-day public disclosure policy.

Patches remedying the flaw were issued on April 14 – a little over a month after disclosure – in versions going back to 2.17.x.

Changes can be further backported by applying commit 9a6bbee, according to Wilhelm, since “the full release includes extra checks for git fsck”, which he said was sufficient to protect clients against the vulnerability.

Wilhelm’s post includes a proof of concept for GitHub.com, which hosts Git repositories and is Git’s most popular credential source.

However, this attack could be executed using any two hosts, courtesy of an absence of constraints on their relationship, indicated Wilhelm.

The researcher also offered a quick, secure fix whereby the credential_from_url rejects newline characters and is rewritten to depend on libcurl directly.

A spokesperson for the Git Project urged users to upgrade to the latest version.

They also confirmed to The Daily Swig that the disclosure process unfolded as normal: the vulnerability was disclosed to the closed git-security mailing list, comprising “developers with relatively high familiarity with the entire codebase” and those “responsible for managing binary packaging of the software to various distributions.”

Once a fix was prepared, reviewed, and agreed they arranged “coordinated disclosure and release among distro people and other stakeholders.

“As the fix itself was relatively straight-forward, the time it took between the initial contact and the release was spent mostly to wait for the slowest participant in the coordinated disclosure process.”

The Daily Swig has also contacted Wilhelm for comment.

This article was updated on April 15 with comment from the Git Project.