4 ms·

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 sig

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.
  - dickjocke 7y ago
    thank you OP and everyone. I have that shaky initial understanding but makes much more sense.
- air7 7y ago
  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.
  - dickjocke 7y ago
    that makes a lot more sense, thank you
gowld 7y ago
> 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

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.
- dickjocke 7y ago
  thank you OP and everyone. I have that shaky initial understanding but makes much more sense.
air7 7y ago
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.
- dickjocke 7y ago
  that makes a lot more sense, thank you

gowld 7y ago

> 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