Closed
Bug 1382116
Opened 8 years ago
Closed 8 years ago
The XPI signature mechanism is broken (sha-1 collisions)
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
DUPLICATE
of bug 1169532
People
(Reporter: yawning, Unassigned)
Details
The XPI signature mechanism documented at https://wiki.mozilla.org/Add-ons/Extension_Signing is broken and can be bypassed by any adversary capable of producing SHA1 collisions.
Signing a file containing the hash(es) (`mozilla.sf`) of a file containing a list of hash(es) (`manifest.mf`) is questionable to begin with, and is entirely broken when the hash algorithms are MD5 and SHA1.
The "easiest" way for an adversary to exploit this would be to replace one of the JS files in a signed XPI with something malicious that has identical hashes to an existing file, though the `manifest.mf` file could also be replaced entirely.
It is worth emphasizing that the fact that there are two and not one broken Merkle-Damgard construction hashs per entry adds little to no difficulty to the attack (See: Joux, A., "Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions" and all follow up research into this class of attacks).
Recommended short term mitigation:
* If not already implemented, the XPI validation should use the counter-cryptanalysis hardened SHA1 variant produced as part of the https://shattered.io/
Recommended fixes:
* Change the hash algorithm(s) to something that isn't broken.
* Re-think how the signing mechanism is implemented all together, to prevent recurrence and lots of pain on a hash algorithm break (Eg: sign each file individually, and/or sign the manifest directly).
* Sign file length metadata to mitigate length extension attacks.
* Revoke the existing key, and invalidate all XPIs that use SHA1/MD5. Till then, all existing signed addons are potential vectors for malicious code execution.
nb: While this is flagged as a security problem that should be kept secret, it is https://trac.torproject.org/projects/tor/ticket/22971 under the assumption that "adversaries capable of producing SHA1 collisions, are also capable of and do actively look at code".
Updated•8 years ago
|
Component: Security → Add-ons Manager
Product: Firefox → Toolkit
Summary: The XPI signature mechanism is broken. → The XPI signature mechanism is broken (sha-1 collisions)
Comment 1•8 years ago
|
||
Thanks for reporting, bug 1357815 is already in the works.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Comment 2•8 years ago
|
||
Opening this up given the tor ticket and the dupe are public.
Group: firefox-core-security
Comment 3•8 years ago
|
||
"can be bypassed by any adversary capable of producing SHA1 collisions."
There is still, to this day, no second preimage attack on SHA1. (There isn't even one for MD5). So unless someone that spends multiple hundred thousand dollars creates 2 addons with a collision (with the shattered attack), *and* manages to have one of them (which will have some suspicious random bytes in them) to go through review undetected[1], there is no practical attack.
1. also, both collisioning addons would probably contain the attack code (cf. how the shattered PDFs worked), because pulling off an attack without the attack code in both would require much more resources than shattered required.
You need to log in
before you can comment on or make changes to this bug.
Description
•