Watershed SHA1 collision just broke the WebKit repository, others may follow
-
I don't know what the bigger WTF is here, the fact that SVN crashes this badly with files that have the same sha1 hash, that the WebKit team are still using SVN, or that their solution was to zip the offending files so that they can continue using SVN...
-
@Ashley_Sheridan said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
I don't know what the bigger WTF is here, the fact that SVN crashes this badly with files that have the same sha1 hash, that the WebKit team are still using SVN, or that their solution was to zip the offending files so that they can continue using SVN
The biggest is that they tested it on the WebKit repo, not a specific testing repo.
-
It's not just SVN: GIT is also affected, though it seems no-one's corrupted a GIT repo yet.
-
@RaceProUK said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
It's not just SVN: GIT is also affected, though it seems no-one's corrupted a GIT repo yet.
Update: I tried, but it seems GIT doesn't suffer the same way as SVN.
-
@RaceProUK If Git notices a collision then the oldest object wins, so existing repo's and forks are not impacted. It's only when you clone a repo and expect the HEAD to match a given SHA-1 hash that you're at risk, but even then there might be things in the Git history which no longer make sense so that an attack gets detected.
Linus meanwhile isn't quite concerned that there'll be an attack on Git soon, though he agrees to change to a different hash just to be sure.
EDIT: Mind you, "signed commits" might be at risk, but then the attacker would still need to forge an entire commit object and manage to insert it into an online repo's object store without any reviewer noticing. If anyone else synced the "harmless" commit with a collision to the repo first then everybody else will download that one.
-
@JBert That repo is a fresh one created minutes ago, with two files of the same age (in one commit).
Anyway, what I wanted to test is if having two files with the same SHA1 hosed a GIT repo the way it hoses an SVN repo, and it appears it doesn't. I've done two commits since those PDFs went in, and there was no error: everything worked as it normally does.
-
-
@anonymous234 They say a picture is worth a thousand words. In the case of that picture, the thousand words are
What the fuck? I'm confused.
200 times.
-
-
@RaceProUK I don't think git is affected in the sense that the two PDFs would break it, I think it's affected in the sense that two different commits could have the same hash. But maybe git does use SHA1 for files too and I never bothered to memorize that information.
-
Would be interesting to see how it affects
git lfs
-
@RaceProUK I like that the script literally just blocks one hash.
Smallest blacklist ever.
-
@JBert said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
Linus meanwhile isn't quite concerned that there'll be an attack on Git soon, though he agrees to change to a different hash just to be sure.
Maybe Mr Torvalds (and the Subversion people) should have started working on that when SHA-1 was officially deprecated 13 years ago.
Idiots.
Edit: turns out Git development started after SHA-1 was deprecated.
-
@anonymous234 said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
Can I just say that I don't understand this diagram at all?
It's pretty simple. PDFs contain "stuff". The amount and contents of the "stuff" is arbitrary, resulting in "regular stuff", "double stuff", "mega stuff", and even "inverted stuff" PDFs that look the same....
::munch, munch::
What were we talking about again?
-
@LB_ said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
But maybe git does use SHA1 for files too and I never bothered to memorize that information.
They use SHA-1 to generate content descriptors of both the files and the manifests that describe what files (by content descriptor) are used to make up a particular commit.
-
Linus Torvalds:
-
@anonymous234 As far as I can tell, it's pointing out that the beginning of PDFs are uniform (this is an identical-prefix collision attack, and shouldn't work for unrelated messages, but that's still fairly big considering how almost all message formats are designed), and that there's a handy place for them to put near-collision block pairs. It'll be a little more clear when they disclose the code later.
-
@anonymous234 said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
Can I just say that I don't understand this diagram at all?
Nah, it makes perfect sense if you understand PDF document structure.
-
@heterodox said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
@anonymous234 As far as I can tell, it's pointing out that the beginning of PDFs are uniform (this is an identical-prefix collision attack, and shouldn't work for unrelated messages, but that's still fairly big considering how almost all message formats are designed), and that there's a handy place for them to put near-collision block pairs. It'll be a little more clear when they disclose the code later.
Identical prefix and indentical suffix.
-
@Weng said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
Identical prefix and indentical suffix.
Also, a place in the middle to hide a bunch of random bytes that the user will never see (or see the effect of).
-
@RaceProUK said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
@Ashley_Sheridan said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
I don't know what the bigger WTF is here, the fact that SVN crashes this badly with files that have the same sha1 hash, that the WebKit team are still using SVN, or that their solution was to zip the offending files so that they can continue using SVN
The biggest is that they tested it on the WebKit repo, not a specific testing repo.
As I understand it they weren't testing the repo. They were checking in test code that was supposed to check if webkit breaks with those files. Then that became irrelevant because it broke their repo instead.
-
@witchdoctor Yeah, that clarification wasn't there when I first posted :P
-
@heterodox I get the prefix+JPEG image object that can be filled with gibberish+suffix.
But why are the two arrows relevant? Why does PDF content reference image object? And why does the JPEG content seem to expand to the entire document on the left?
-
@anonymous234 I think they're trying to indicate how the similarities in the content arise from the common header and trailer.
-
@anonymous234 the content block references the image because the image can (but need not) be used on one or more of the content pages. The image block references the image properties object because image properties can be used by more then one image.
The "JPEG content expands into the entire document content" thing appears to be a restatement of "this image can appear anywhere"
-
@dkf said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
@Weng said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
Identical prefix and indentical suffix.
Also, a place in the middle to hide a bunch of random bytes that the user will never see (or see the effect of).
You sure as hell don't need a JPEG to dump random bytes into a PDF where the user won't ever see them. That file spec has tons of holes to hide things, including an entire object type that is a no op in the spec, intended for local extensions to the format.
-
@anonymous234 said in Watershed SHA1 collision just broke the WebKit repository, others may follow:
Maybe Mr Torvalds (and the Subversion people) should have started working on that when SHA-1 was officially deprecated 13 years ago.
Idiots.
Edit: turns out Git development started after SHA-1 was deprecated.
I'm not sure what you're referring to. Git development began in 2005. Around that same time, theoretical attacks on SHA-1 were proposed but SHA-1 wasn't deprecated by NIST until 2011.
Of course, Git and SVN shouldn't be using something that was deprecated 6 years ago.
-
@El_Heffe
-
It's in this PDF but it's not loading right nowOK, it works now (but the preview is borked)
The results presented so far on SHA-1 do not call its security into question.
However, due to advances in technology, NIST plans to phase out of SHA-1 in favor of
the larger and stronger hash functions (SHA-224, SHA-256, SHA-384 and SHA-512) by
2010.8-25-2004
I don't know if it was an "official deprecation" but planning to phase it out counts as one to me.