]> git.ipfire.org Git - thirdparty/git.git/commit
credential: disallow Carriage Returns in the protocol by default
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Mon, 4 Nov 2024 13:48:22 +0000 (14:48 +0100)
committerJohannes Schindelin <johannes.schindelin@gmx.de>
Tue, 26 Nov 2024 19:24:04 +0000 (20:24 +0100)
commitb01b9b81d36759cdcd07305e78765199e1bc2060
tree1b1ef503233ddfcb23686e0cd415f008bf35631a
parent7725b8100ffbbff2750ee4d61a0fcc1f53a086e8
credential: disallow Carriage Returns in the protocol by default

While Git has documented that the credential protocol is line-based,
with newlines as terminators, the exact shape of a newline has not been
documented.

From Git's perspective, which is firmly rooted in the Linux ecosystem,
it is clear that "a newline" means a Line Feed character.

However, even Git's credential protocol respects Windows line endings
(a Carriage Return character followed by a Line Feed character, "CR/LF")
by virtue of using `strbuf_getline()`.

There is a third category of line endings that has been used originally
by MacOS, and that is respected by the default line readers of .NET and
node.js: bare Carriage Returns.

Git cannot handle those, and what is worse: Git's remedy against
CVE-2020-5260 does not catch when credential helpers are used that
interpret bare Carriage Returns as newlines.

Git Credential Manager addressed this as CVE-2024-50338, but other
credential helpers may still be vulnerable. So let's not only disallow
Line Feed characters as part of the values in the credential protocol,
but also disallow Carriage Return characters.

In the unlikely event that a credential helper relies on Carriage
Returns in the protocol, introduce an escape hatch via the
`credential.protectProtocol` config setting.

This addresses CVE-2024-52006.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Documentation/config/credential.txt
credential.c
credential.h
t/t0300-credentials.sh