Hacker News Reader

Comment by dickjocke | Hacker News Reader

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?

View on HN

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/), and I'm sure there's many more such examples out there.

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.

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.

thank you OP and everyone. I have that shaky initial understanding but makes much more sense.

He said "innocent-looking device driver".

The good driver is actually padded so that it can be later replaced with the bad driver. I.E This doesn't allow the attacker to replace any driver, but only one they prepared in advance to look innocent but have the right structure.

that makes a lot more sense, thank you

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.

> you'd need to convince a signing authority to sign the code.

Not necessarily. You can also self-sign or just announce the hash, let the public inspect and test your good driver for a year, and then ship the bad driver to people who only check the hash

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.

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-c...

Please don't feed the cancer which is AMP.

https://techcrunch.com/2008/12/30/md5-collision-creates-rogu...

Please don't overegg the issue with AMP by comparing it to cancer.

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.

Reply on news.ycombinator.com