Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus on Git and SHA-1

plus.google.com

Post reply on HN
Print view View original

141–150 of 187 posts

Re: Linus on Git and SHA-1

#141

Post by azernik »

joatmon-snoo wrote: post #106

The actual mailing list discussion thread can be found here, and is infinitely more informative than any of the bull being spouted in this thread: http://public-inbox.org/git/20170226004657.zowlojdzqrrcalsm@...

My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizon and they should speed up their hash-replacement efforts.

This latter leads into the problems with Linus' positions in particular. In that thread, does not take seriously the threats that this poses to the broader git userbase, because he only seems to care about the kernel use-case: trusted hosting infrastructure at kernel.org (itself an iffy assumption, given previous hacks and the use of mirrors), and the exclusive storage of human-readable text in the repo which makes binary garbage harder to sneak in. These do not apply to most users of git. His rather extreme public position (paraphrased, "our security doesn't depend on SHA1") is even more troubling - it absolutely does depend on SHA1, this just isn't (yet) a strong enough attack to absolutely screw over the kernel. A stronger collision attack (eg a chosen-prefix as opposed to identical-prefix, or godforbid a pre-image attack) would absolutely invalidate the whole git security model.

Re: Linus on Git and SHA-1

#142

Post by ProblemFactory »

posterboy wrote: post #136
leoh wrote: post #111

Earlier quoted context omitted.

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

> random odd generated crud in the middle of your source code, you will absolutely notice like non-printing characters in comments? Or, you know, random odd generated crud https://github.com/torvalds/linux/tree/master/firmware/radeo...

If you were planning on getting a compromised binary blob into a git repository, you would not bother with the whole SHA-1 collision and switching things out later.

You would just build a hidden backdoor into the first binary blob, like a deliberately omitted array bounds check if specific parameters are used. Reviewers and tests won't find that in complied binary code either, it's much easier to hide than large amounts of garbage data, and you even get to keep plausible deniability of it being a honest mistake if discovered.

Re: Linus on Git and SHA-1

#143

Post by Dylan16807 »

posterboy wrote: post #133
Dylan16807 wrote: post #127

Earlier quoted context omitted.

> Just as they noticed the intrusion on kernel.org servers after how long? It doesn't work retroactively. That crud needs to be there in the initial commit when it's accepted by multiple people. > Couldn't it just happen that an important bugfix isn't recorded because the hash collides? The hashes will never collide if there's no attacker. And that bugfix would have to have a blob of crud in the 'good' version, which…

> It doesn't work retroactively. That crud needs to be there in the initial commit when it's accepted by multiple people. Do you assume that a proper preimage-attack would be needed? Instead, the good looking object could be committed, I guess after reading https://news.ycombinator.com/item?id=13721237 edit: > And that bugfix would have to have a blob of crud in the 'good' version Looking at google's POC, the collidi…

> the good looking object could be committed

In source code there will be an obvious block of "hash was attacked here" crud in each file. The 'good looking' object will function non-maliciously, but it will be obvious that something is up.

> I'm still not sure if "never" is a rounding error, hyperbole (which would be ill advised talking to laymen), or actual fact (that source files due to the reduced entropy in byte patterns could in fact never ever collide, which I doubt)

"never" is to be read as "over a billion times more unlikely than all life on the planet suddenly being wiped out". It's not going to happen accidentally.

Re: Linus on Git and SHA-1

#146

Post by ProblemFactory »

stinos wrote: post #123
leoh wrote: post #111

Earlier quoted context omitted.

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice Unless I'm misunderstanding how this would work in practice (I assume commits being added under my name or existing commits being modified?), I'm abolutely not buying that though. Way too general, no? I would likely notice something like that, but I know enough colleagues who are just as likely to not notice. M…

Sure, most people don't review all the code that they pull.

But if you are in a position to insert "garbage data" into a commit in preparation for an attack, it will be much easier to insert malicious but safe-looking code in the first place. Omit an array bounds check, disable SSL certificate validation, or anything else that looks like a mistake but will allow you to compromise the running code later.

Re: Linus on Git and SHA-1

#147

Post by posterboy »

ProblemFactory wrote: post #142
posterboy wrote: post #136

Earlier quoted context omitted.

> random odd generated crud in the middle of your source code, you will absolutely notice like non-printing characters in comments? Or, you know, random odd generated crud https://github.com/torvalds/linux/tree/master/firmware/radeo...

If you were planning on getting a compromised binary blob into a git repository, you would not bother with the whole SHA-1 collision and switching things out later. You would just build a hidden backdoor into the first binary blob, like a deliberately omitted array bounds check if specific parameters are used. Reviewers and tests won't find that in complied binary code either, it's much easier to hide than large amou…

also to divert my criticism, that directory is not for new commits

Re: Linus on Git and SHA-1

#148

Post by frik »

Can someone correct me. SVN/Subversion and GIT are affected by SHA-1 problem. SVN uses SHA-1 internally, but exposes only a numeric int as revision. GIT uses SHA-1 internally and as revision. So if someone commit a modified PDF that collides he can run havoc on both SVN and GIT at the moment. It seems easier to fix the issue in SVN than GIT.

Re: Linus on Git and SHA-1

#149

Post by hannob »

frik wrote: post #148

Can someone correct me. SVN/Subversion and GIT are affected by SHA-1 problem. SVN uses SHA-1 internally, but exposes only a numeric int as revision. GIT uses SHA-1 internally and as revision. So if someone commit a modified PDF that collides he can run havoc on both SVN and GIT at the moment. It seems easier to fix the issue in SVN than GIT.

It's a somewhat different issue.

Git can probably not be havoced by committing two colliding files (and doing so would require doing another chosen prefix attach with a git blob header). But git looses cryptographic integrity promises due to this attack (aka: you can have different source trees with different histories leading to the same top commit hash). svn never had any cryptographic integrity to begin with.

Re: Linus on Git and SHA-1

#150

Post by kzrdude »

frik wrote: post #148

Can someone correct me. SVN/Subversion and GIT are affected by SHA-1 problem. SVN uses SHA-1 internally, but exposes only a numeric int as revision. GIT uses SHA-1 internally and as revision. So if someone commit a modified PDF that collides he can run havoc on both SVN and GIT at the moment. It seems easier to fix the issue in SVN than GIT.

Sure, here's a correction: There has been no evidence of havoc or repo corruption in git.

It appears that to even try to attack git you'd need to spend the same amount of work again ($110K or what it was) to create a new collision with the right git object headers.

Post reply on HN