Git: Newline injection in credential helper protocol | Hacker News Reader

Git: Newline injection in credential helper protocol

bugs.chromium.org

105 pointstodotask21 comments

Here's a note about it in the Git mirror repo:

Malicious URLs may cause Git to present stored credentials to the wrong server - https://github.com/git/git/security/advisories/GHSA-qm7j-c96...

..And the commit that fixed it:

https://github.com/git/git/commit/9a6bbee8006c24b46a85d29e7b...

Previously on HN (2 comments, yesterday): https://news.ycombinator.com/item?id=22876108

thanks

I wonder how this fix behaves with '\r' on all platforms. Obviously the primary systems (windows/osx/linux/bsd) all use \n or \r\n, but I'm wondering if Git has been ported to more obscure systems that only use \r [0], and how this fix would behave there.

[0] https://en.wikipedia.org/wiki/Newline#Representation

That was discussed before the fix, but it doesn't matter. The helper protocol specifies a raw newline as the delimiter, and both sides of the conversation parse on that.

Fixed in latest Git clients: v2.26.1, v2.25.3, v2.24.2, v2.23.2, v2.22.3, v2.21.2, v2.20.3, v2.19.4, v2.18.3, and v2.17.4. https://lkml.org/lkml/2020/4/14/1136

This is your reminder that there is no such thing as computer security in the year 2020. Treat your computers accordingly.

What does "treat your computers accordingly" mean to you?

Do not put any data that would devastate you if it became public into any networked computer.

I was thinking about how the government still collects a lot of forms on paper. On the one hand, it's costly and inefficient waste. On the other hand, no one from Bulgaria can sneak off with all of the VA's paper forms without someone noticing the long line of semi-trucks driving away from the building…

https://en.wikipedia.org/wiki/Office_of_Personnel_Management...

If only...

FWIW I have some paper forms that they couldn't reproduce when I submitted a FOIA request. It's just everything post-2000 when the web based system was first instituted.

Well, that's something I guess.

https://github.com/git/git/commit/9a6bbee8006c24b46a85d29e7b...

Hmm, it makes sense to catch the error when writing, but I wonder why not fix the parser as well? https://example.com?foo=bar is a valid URI reference per RFC 3986 and doesn’t look so malicious yet it’s still parsed wrong. (I didn’t bother to track down and read the parser code.)

The parser problem made it worse, but it was neither necessary nor sufficient for the vulnerability. We are fixing it, but decided to leave it out of the critical release path. See https://lore.kernel.org/git/20200414214304.GA1887601@coredum...

Cool, thanks for the follow-up.

"Git uses a home-grown URL parser"... Is this the root cause of the issue?

Reading that point reminded me of a recent article where a security researcher found an exploit due to the URL parser in Safari:

Unauthorized access to cameras in Safari on macOS and iOS - https://www.ryanpickren.com/webcam-hacking

And another one related to URL parsing:

The unexpected Google wide domain check bypass - https://bugs.xdavidhu.me/google/2020/03/08/the-unexpected-go...

No, it's not the root cause, though it did exacerbate it. See the comment in https://news.ycombinator.com/item?id=22890633.

Does this mean it's safer to authenticate using public-private keys (SSH) than passwords (SSH, HTTP)?

i think it's fair to say that asymmetric keypair authentication is more secure than passwords in general.

Asymmetric PAKEs level the playing field considerably.

The way we typically use passwords (you just outright tell the other party the password and we hope that's fine) is terrible security design. But everything about passwords is pretty terrible, their only "benefit" is that they're easy which is often undone by measures layered on top to try to deliver security, such as password rotation policies.

But this was still a dumb bug.

Reply on news.ycombinator.com