The first SHA1 collision .

[firewalker]

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Alexander.

[SingedFingers]

That's going to be interesting.



^^ NSA data centre in Utah.

[Monkeh]

SHA1? People still use that?

[Bud]

Will be for quite awhile.

[SingedFingers]

Lots of things use SHA1 and won't be changing. Git for example.

[Monkeh]

Lots of things use SHA1 and won't be changing. Git for example.

That sort of application is not really concerned about artificial collisions.

[SingedFingers]

It is a big issue. Consider if you host your commercial product in github/gitlab/getweb remotely. If you can replace a single object in the git repository (via warrant or exploit) then a file can have malicious code infected without the repo owner knowing or the hashes or refs being changed. Next person who does a fresh pull (or a build server that does it) gets the infected file.

For ref, managing these risks is the day job. I had a bit of a black hat past (not script kiddie stuff either)

[Monkeh]

It is a big issue. Consider if you host your commercial product in github/gitlab/getweb remotely. If you can replace a single object in the git repository (via warrant or exploit) then a file can have malicious code infected without the repo owner knowing or the hashes or refs being changed. Next person who does a fresh pull (or a build server that does it) gets the infected file.

The checksum in git is not intended to be a method of securely verifying the content and, being SHA1, I haven't ever even considered treating it as such.

[SingedFingers]

It's not quite that simple. It was (badly) designed to be a consistent reference to an object and was never a security feature, you are right.

However that doesn't mean it can't be exploited, which is the issue. Most of the exploits on the market emerged from inconsistencies and bad theoretical designs.

You can use it destructively too to provide two objects contents with the same ref for example.

A consistency violation is always an attack vector.

[Bud]

Nothing happens fast in big enterprises. Also the risk will be evaluated and if it is within the company's risk bounaries it will be put on the back burner.

[rrinker]

 Considering it cost something like $110K of compute time on Amazon cloud AND they sort of knew what they were shooting for (the two PDF files were specifically crafted) - I don't see this of being of much import to the average person. Like all risks it needs to be evaluates. If spending $110K can net you a few million return if successful then I'd make sure I was not using anything SHA1 any more. If spending $110K nets you the content of my bank account then I'll sacrifice for the good of society in the hopes of driving the bad guys into bankruptcy.

[Monkeh]

Considering it cost something like $110K of compute time on Amazon cloud AND they sort of knew what they were shooting for (the two PDF files were specifically crafted) - I don't see this of being of much import to the average person.

Yet.

[rrinker]

 Indeed. Not YET. So no need for people to go running around like a bunch of nutcases waving their hands that this is the end of the world. We've know we should move away from SHA-1 for years now, so as long as we continue to do so, all it well.

[SingedFingers]

It's well inside the budget of a state level attack already.

Also don't forget that botnets and stolen AWS keys are a big thing.

[SeanB]

Just remember SHA1 is also used by a lot of storage deduplicators to store a single instance of a particular chunk of data in a storage array. Think of a system that backs up a load of computers or data, where they look for duplicate data blocks and then only store one copy, using the rest via pointers. This can be a method to poison a backup series, or poison an image for a target storage system, replacing part of the data ( like the boot image for PXE booting of diskless workstations or a system image of something like a set of virtual server instances) with a version of your choosing, and then this is going to be deduplicated to all the systems on the next instance.

Think of something like AWS, which uses this to run up a virtual server per process in under a second, or a big business or agency that uses diskless workstations for thin clients or other such stateless user interfaces.

[DJohn]

If I'm understanding the story right, it has already done damage.

Webkit is a widely used browser engine.  They use SHA1 as part of the system for identifying documents: if two documents have different hashes, you know they're different and don't have to compare them in full.  Now that a pair of colliding documents have been created, someone (from what I understand - I might have this wrong) decided that they should test that it handles them correctly.

So they wrote a test and submitted it to their source control, along with the two colliding pdf files as test data.  This is a reasonable and responsible thing to do.

Unfortunately, the source control system they use also uses SHA1 for identifying files.  Having two different files with the same hash broke the database, in a way that couldn't be fixed by rolling back the submit.  They had to restore from a mirror.

Not all attacks come from an unfriendly attacker!

https://bugs.webkit.org/show_bug.cgi?id=168774

[SingedFingers]

Yep. This is exactly why you can't identify a random piece of data from the universe with a hash. It's playing a poor probability game.