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

Linus' reply on Git and SHA-1 collision

marc.info

Post reply on HN
Print view View original

151–160 of 273 posts

Re: Linus' reply on Git and SHA-1 collision

#151

Post by dfox »

dingo_bat wrote: post #51
stickfigure wrote: post #25

Several years ago I worked on a security product that used git as a sort of tripwire-type database. Since SHA1 was considered inadequate for Real Security, we had to hack jgit to use SHA256. It took a stupid amount of work - the 160-bit hash size was scattered all over the codebase in countless magic numbers. But it worked. The product was cancelled. I always wondered if the patch would be of any use to anyone.

> I always wondered if the patch would be of any use to anyone. You think? I dunno why you wouldn't try to submit a pull request though.

Because for inclusion into upstream git it has to be done in some at least somewhat backward compatible manner, which is not exactly trivial.

Re: Linus' reply on Git and SHA-1 collision

#152

Post by hvidgaard »

olavgg wrote: post #148
hvidgaard wrote: post #135

Earlier quoted context omitted.

Moore's law still holds, and is expected to hold true until at least 2025 (see wikipedia). I don't think it will be done by then, but that is just guess work.

How much faster is a cpu from 2012 and a cpu from today when you compare them by single thread performance @ 3 ghz.

Moore's law is not about single thread performance, and attacks like this are easily parallelized anyway. Not to mention that fixing them at 3Ghz is just trying to coherce the conslusion to be that we have seen little gain in the last 5 years.

Re: Linus' reply on Git and SHA-1 collision

#153

Post by dozzie »

shasheene wrote: post #146
dozzie wrote: post #141

Earlier quoted context omitted.

Erm... Which ones?

I believe Homebrew on macOS uses it for formulae (Ruby scripts to actually download and build the application)

Well, I don't hear too often about a fleet of servers running MacOS (because this branch of comments started with provisioning in a fleet of servers).

Also, from rants I hear about Homebrew and its breaking random libraries on upgrades, I don't think it should be mentioned as it was state-of-the-art or something.

Re: Linus' reply on Git and SHA-1 collision

#154

Post by jwilk »

hvidgaard wrote: post #124
dlubarov wrote: post #116

Earlier quoted context omitted.

> Git prepends type and length, that makes an attack significantly more difficult, and certainly you cannot just directly translate the pdf attack to Git. With the attack vectors discussed above, the type would always be blob. I don't think the length field is much help either; see https://news.ycombinator.com/item?id=13720725

The length field makes the attack significantly more difficult. In the publish attack, you take 2 fixed input and prepend special data to make the collision. With Git, you have additional constraint. Either it needs to be of exact length, this may or may not be an issue, but most likely is unless we find a new weakness in SHA-1, or you must be able to handle the changing input. In all the examples in your link, while…

> The length field makes the attack significantly more difficult. In the publish attack, you take 2 fixed input and prepend special data to make the collision.

That's not how the attack works. Not at all.

Re: Linus' reply on Git and SHA-1 collision

#155

Post by disiplus »

fryguy wrote: post #75
notfed wrote: post #56

Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…

That's not entirely true. You could fork a popular git repo, and then make some kind of patch for a bug in some seldomly changed file. Then force a collision in the new file with the benign change as well as your poisoned version. Then they could convince you to pull in the changes. Then they could reset their repository to the one with the poisoned version and anyone who pulls from them first would get the poisoned…

thats stretching it. if you could convince anybody to pull from you then why even bother to go to a great expense of creating a collision.

Re: Linus' reply on Git and SHA-1 collision

#156

Post by pvg »

astrodust wrote: post #131
paulddraper wrote: post #60

Earlier quoted context omitted.

Mach 6 is a heck of a slow meteorite. But the if a small meteorite (only a few grams) were traveling that slow, 1.5 inches of titanium would do quite a bit.

I'm not sure how fast these go once they hit the atmosphere. I've seen numbers in the 15 to 25km/hr range, which is pretty damned fast, but how much do they slow down in the thicker atmosphere closer to the ground?

That depends on the size. Smaller ones just never make it to the ground - take a look at this table:

https://en.wikipedia.org/wiki/Impact_event#Airbursts

One they get big enough, they slow down from ludicrously fast to still ludicrously fast. The smallest impactor shown in that table enters at 17 km/s, loses 90% of its energy traversing the atmosphere and smacks the ground at nearly 5km/s. You'll probably want to take your titanium armour and stand somewhere else.

Re: Linus' reply on Git and SHA-1 collision

#157

Post by moonshinefe »

Correct me if I'm wrong, but if you're letting untrusted people push to your git repositories, you're pretty much screwed anyway.

Given a case where someone with permission to push gets compromised and a malicious actor can pull this sha-1 attack off, aren't there bigger problems at hand? The history will be there and detectable or if they're rewriting history, usually that's pretty noticeable too.

I may be totally missing a situation where this could totally screw someone, but it just seems highly unlikely to me that people will get burned by this unless the stars align and they're totally oblivious to their repo history. So I guess I agree with the "the sky isn't falling" assessment.

Re: Linus' reply on Git and SHA-1 collision

#158

Post by throwayguestman »

dozzie wrote: post #125
falsedan wrote: post #123

Earlier quoted context omitted.

Because, when provisioning a new server, where else can you get it from?

From a custom package you have built? Did you know that RPMs and DEBs don't grow on magical trees, but are built?

So, the problem still stands, theoretically.

Not only do you likely need to populate your host with packages not from your host. But also, your host will also still be connect to a public net, even if only indirectly (e.g. private net), and hence potentially manipulated.

Re: Linus' reply on Git and SHA-1 collision

#159

Post by jwilk »

trengrj wrote: post #23

So would it be possible to migrate to a different hash seamlessly?

https://github.com/cr-marcstevens/sha1collisiondetection implements a hash that is compatible with SHA-1 for all non-nefarious purposes, and has no known weakneses.

Somebody already submitted patch series to (optionally) use it in git in place of SHA-1:

https://www.spinics.net/lists/git/msg296714.html

Re: Linus' reply on Git and SHA-1 collision

#160

Post by raverbashing »

Perseids wrote: post #142
stonogo wrote: post #115

Earlier quoted context omitted.

Sounds like sentence three is where you got it wrong. You should be pulling your software to a development host, building it after verification, and uploading the deployment package to an artifact repository inside your security perimeter. Sentence three becomes 'pull library X from my artifact server.' There is no way to securely deploy a package directly from the internet. The sooner you understand that, the sooner…

> There is no way to securely deploy a package directly from the internet. Fetching a file from the internet and verifying it against a hash or signature is the only way to securely deploy a package from the internet. This is exactly one of the use cases theses cryptographic primitives are built for. Don't blame the users when they utilize the tools the way they are supposed to be, blame the tools when they fail when…

apt-get can (and do) check signatures of repos

But yeah, you could put an unverified repos to be used

Post reply on HN