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

Announcing the first SHA-1 collision

security.googleblog.com

Post reply on HN
Print view View original

91–100 of 524 posts

Re: Announcing the first SHA-1 collision

#91

Post by chaosfox »

mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

this isn't quite true, bittorrent have checksums for each piece in the torrent, I not saying its impossible to do but its significantly harder than just finding 2 files with the same hash.

Re: Announcing the first SHA-1 collision

#92

Post by antoinealb »

anilgulecha wrote: post #67
contravariant wrote: post #62

Earlier quoted context omitted.

>* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Maybe I'm mistaken, but isn't the purpose of those mainly to verify that you've downloaded the file correctly? At least, the use of MD5 suggests that this is the case.

Correct, and if you have 2 images that have the same hash, you can serve one or the other at different times. This is the attack.

SHA hashes cannot protect you against the distribution site getting compromised and the hash replaced. That is why most package manager include a form of cryptographic signatures (e.g. Ed25519 for OpenBSD's). SHA and MD5 hashes are just used to protect against accidental corruption, not targeted attacks.

Re: Announcing the first SHA-1 collision

#93

Post by pgeorgi »

anilgulecha wrote: post #67
contravariant wrote: post #62

Earlier quoted context omitted.

>* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Maybe I'm mistaken, but isn't the purpose of those mainly to verify that you've downloaded the file correctly? At least, the use of MD5 suggests that this is the case.

Correct, and if you have 2 images that have the same hash, you can serve one or the other at different times. This is the attack.

If you can switch between the images, you can also switch hashes. Without a signature they serve _only_ for making sure the network didn't barf into your stream.

Re: Announcing the first SHA-1 collision

#94

Post by simias »

babyrainbow wrote: post #86
mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

Malware in a video? Is that possible? How does it work?

You could replace the video by an executable probably, I'm sure many users would launch it, especially if the source of the torrent is "reputable" and with positive comments.

Alternatively you could exploit a vulnerability in a codec library or something similar.

Re: Announcing the first SHA-1 collision

#96

Post by ktta »

babyrainbow wrote: post #86
mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

Malware in a video? Is that possible? How does it work?

You could have a buffer overflow attack talking advantage of a specific popular video player out there.

Since video players are usually not very security focused, someone determined could do it.

And since video torrents are unzipped, a single chunk can be replaced with the malicious chunk with the attack code. It can look like a tiny jitter depending on the chunk size/total video size.

Re: Announcing the first SHA-1 collision

#97

Post by avar »

geocar wrote: post #42
giovannibajo1 wrote: post #20

Earlier quoted context omitted.

This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the same. So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users. What is currently st…

> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. I'm not convinced that's good enough. In git, the SHA1 is always the hash of a gzip, which is subject to tricks[1] where a header might be prepared and then some padding inserted to collide a malicious tail. [1]: http://swtch.com/r.zip

No, Git does not hash its internal gzip'd content to produce hashes. It purely hashes the uncompressed content you give it as-is. Any compression like gzip is purely done internally as an optimization and has no impact on hashes.

Re: Announcing the first SHA-1 collision

#99

Post by koolba »

pgeorgi wrote: post #88
koolba wrote: post #69

Earlier quoted context omitted.

Torrents have a tree of hashes for the parts. That allows validating pieces without the entire file (which is also validated at the end). Probabilistically, the hashes of the parts would not match even if the top level hash matched.

You could (try to) collide one of the blocks at the end of the tree. The tree of hashes will still be the same since the hash of the block didn't change. Then join the torrent with a client that doesn't download but only upload that block (there will be some that will pick it from you). Many legit copies, except for those that were so unlucky to fetch the block from you. If you manage to build such a block based on o…

> You could (try to) collide one of the blocks at the end of the tree. The tree of hashes will still be the same since the hash of the block didn't change.

Except you can't do that as this isn't a preimage attack. You can't create an arbitrary bad file matching an existing SHA-1 with this.

Re: Announcing the first SHA-1 collision

#100

Post by jerf »

geocar wrote: post #42
giovannibajo1 wrote: post #20

Earlier quoted context omitted.

This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the same. So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users. What is currently st…

> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. I'm not convinced that's good enough. In git, the SHA1 is always the hash of a gzip, which is subject to tricks[1] where a header might be prepared and then some padding inserted to collide a malicious tail. [1]: http://swtch.com/r.zip

Nobody's saying it's "good enough". Once we see one attack we expect to start seeing more. What's being pointed out here is that this particular attack does not let you craft custom git repos whose HEAD matches one of an existing repo. Nobody is asserting that to be generically impossible, and this new attack is at least weak evidence that such an attack may eventually be practical.
Post reply on HN