5 ms·

Can you give a specific example of the danger here? I understand the principle behind the attack (kinda). I just don't understand what danger being able to pad

Can you give a specific example of the danger here? I understand the principle behind the attack (kinda). I just don't understand what danger being able to pad two documents to make them collide poses? edit: My guess is that it can be abused to make something that I believe to be library X actually be library Y when I download it from the internet. Lets say I want to download something, and I check the signature provided. Assuming the attacker is able to send me the wrong library via a MITM attack, how can this prefix collision work? It seems that the original library AND the original signature on the library's website have not been altered, so their efforts to use this and make them match are impossible. And it seems like if they can alter the signature on the website and stuff, then all bets are off--why not just send the malicious library at that point?

femto113 7y ago
It’s a step on the same path that led to being able to spoof a CA for MD5 signed certs. https://www.google.com/amp/s/techcrunch.com/2008/12/30/md5-collision-creates-rogue-certificate-authority/amp/ https://www.google.com/amp/s/techcrunch.com/2008/12/30/md5-c...
- ThePowerOfFuet 7y ago
  Please don't feed the cancer which is AMP. https://techcrunch.com/2008/12/30/md5-collision-creates-rogue-certificate-authority/ https://techcrunch.com/2008/12/30/md5-collision-creates-rogu...
  - sofaofthedamned 7y ago
    Please don't overegg the issue with AMP by comparing it to cancer.
    - andrewstuart2 7y ago
      Don't make cancer anything it's not, either. Cancer is just growth of abnormal cells, unconstrained, to the point that it causes harm to the host. That said, maybe AMP is more like a virus. A non-living organism that spreads by infecting living organisms and repurposing them to replicate itself instead of sustaining the organism they were a part of. The more sites adopt AMP, the more everyone else says "well I guess we have to now." Seems pretty viral.
nneonneo 7y ago
Suppose your system uses SHA-1 hashes for codesigning verification (e.g. to load a system driver). I create an innocent-looking device driver and convince a signing authority to sign it. However, secretly I've created a malicious driver (e.g. a rootkit) which collides with my innocent one. Now, I can load the malicious one on your machine - which the signing authority has never seen - using the signing certificate of the legitimate one. This might sound far-fetched; after all, you'd need to convince a signing authority to sign the code. But this is pretty much exactly how Apple's Gatekeeper verification works: your software is submitted to them, and they do some security checks and notarize your bundle (https://developer.apple.com/developer-id/ https://developer.apple.com/developer-id/), and I'm sure there's many more such examples out there.
- dickjocke 7y ago
  Hey OP, im not much of a math guy, I'm getting hung up on this part: SHA1(P1+C1+X) = SHA1(P2+C2+X) for any X. The example above seems like SHA1(GOOD_DRIVER) == SHA1(BAD_DRIVER+C2+X) somehow. How does the C1 and X get appended to the signature of the good driver.
  - cjm42 7y ago
    The good driver consists of P1+C1+X. That's what gets sent to the signing authority. They verify it doesn't do anything bad and return a signature listing SHA1(P1+C1+X). But that signature is also valid for the malicious driver P2+C2+X.
  - nneonneo 7y ago
    Most executable file formats (including drivers) put the code first followed by the data. So you could construct your drivers thusly: GOOD_DRIVER = P1 (good code and some data) + C1 (data) + X (more data) BAD_DRIVER = P2 (bad code and some data) + C2 (data) + X (more data) You'd disguise the random-looking block of C1 data in the middle of the good driver as e.g. a cryptographic key to avoid suspicion. The "more data" part couldn't be modified in the bad driver, but since you can arbitrarily modify P2 this wouldn't be a severe restriction.
Kalium 7y ago
The core of it is that it means a malicious document will pass the check of authenticity when you are using the genuine signature. Someone could tamper with a mirror infect you that way. Absolutely no tampering with the signature would be required, which is what makes this dangerous. Basically, it can be used to send to entirely fake data that you can't tell is fake. Or someone could say that you have your legally binding signature attached to a contract with hash ABC, but then present a different contract with hash ABC but very different terms. Those are the end state. This is a major step closer to that end state. Neither of those scenarios are the case today, but they're now close enough that it's a matter of time. And likely not a lot of time. Time to abandon SHA1.

femto113 7y ago

It’s a step on the same path that led to being able to spoof a CA for MD5 signed certs. https://www.google.com/amp/s/techcrunch.com/2008/12/30/md5-collision-creates-rogue-certificate-authority/amp/ https://www.google.com/amp/s/techcrunch.com/2008/12/30/md5-c...

ThePowerOfFuet 7y ago
Please don't feed the cancer which is AMP. https://techcrunch.com/2008/12/30/md5-collision-creates-rogue-certificate-authority/ https://techcrunch.com/2008/12/30/md5-collision-creates-rogu...
- sofaofthedamned 7y ago
  Please don't overegg the issue with AMP by comparing it to cancer.
  - andrewstuart2 7y ago
    Don't make cancer anything it's not, either. Cancer is just growth of abnormal cells, unconstrained, to the point that it causes harm to the host. That said, maybe AMP is more like a virus. A non-living organism that spreads by infecting living organisms and repurposing them to replicate itself instead of sustaining the organism they were a part of. The more sites adopt AMP, the more everyone else says "well I guess we have to now." Seems pretty viral.

nneonneo 7y ago

Suppose your system uses SHA-1 hashes for codesigning verification (e.g. to load a system driver). I create an innocent-looking device driver and convince a signing authority to sign it. However, secretly I've created a malicious driver (e.g. a rootkit) which collides with my innocent one. Now, I can load the malicious one on your machine - which the signing authority has never seen - using the signing certificate of the legitimate one. This might sound far-fetched; after all, you'd need to convince a signing authority to sign the code. But this is pretty much exactly how Apple's Gatekeeper verification works: your software is submitted to them, and they do some security checks and notarize your bundle (https://developer.apple.com/developer-id/ https://developer.apple.com/developer-id/), and I'm sure there's many more such examples out there.

dickjocke 7y ago
Hey OP, im not much of a math guy, I'm getting hung up on this part: SHA1(P1+C1+X) = SHA1(P2+C2+X) for any X. The example above seems like SHA1(GOOD_DRIVER) == SHA1(BAD_DRIVER+C2+X) somehow. How does the C1 and X get appended to the signature of the good driver.
- cjm42 7y ago
  The good driver consists of P1+C1+X. That's what gets sent to the signing authority. They verify it doesn't do anything bad and return a signature listing SHA1(P1+C1+X). But that signature is also valid for the malicious driver P2+C2+X.
- nneonneo 7y ago
  Most executable file formats (including drivers) put the code first followed by the data. So you could construct your drivers thusly: GOOD_DRIVER = P1 (good code and some data) + C1 (data) + X (more data) BAD_DRIVER = P2 (bad code and some data) + C2 (data) + X (more data) You'd disguise the random-looking block of C1 data in the middle of the good driver as e.g. a cryptographic key to avoid suspicion. The "more data" part couldn't be modified in the bad driver, but since you can arbitrarily modify P2 this wouldn't be a severe restriction.

Kalium 7y ago

The core of it is that it means a malicious document will pass the check of authenticity when you are using the genuine signature. Someone could tamper with a mirror infect you that way. Absolutely no tampering with the signature would be required, which is what makes this dangerous. Basically, it can be used to send to entirely fake data that you can't tell is fake. Or someone could say that you have your legally binding signature attached to a contract with hash ABC, but then present a different contract with hash ABC but very different terms. Those are the end state. This is a major step closer to that end state. Neither of those scenarios are the case today, but they're now close enough that it's a matter of time. And likely not a lot of time. Time to abandon SHA1.