Hi,
In Tails we've been wondering what to do about Firefox's mandatory extension signing [1] in FF52ESR since the opt-out preference that we have been using for FF45ESR will be removed from released versions. Today I found the Tor Browser's solution for tor-browser-52.0.2esr-7.0-2 in commit 584c17c1b3e07239b8dd195e8b91eefb2ff9b2f4; here's an extract:
function isCorrectlySigned(aAddon) { // Add-ons without an "isCorrectlySigned" property are correctly signed as // they aren't the correct type for signing. + if (aAddon.id == "torbutton@torproject.org" || + aAddon.id == "tor-launcher@torproject.org" || + aAddon.id == "https-everywhere-eff@eff.org") { + return true; + } return aAddon.isCorrectlySigned !== false; }
So it's a list of exceptions. In Tails we install two additional extensions we'd like exceptions for:
* a localization-related extension that we generate dynamically *during build*, so signing will be impossible. * Ublock Origin, which we install from Debian, and the signature is missing.
Can this list of exceptions be moved to an external file that we in Tails can modify instead? I think I have exhausted all options we have on our side. [2]
--
I'd also like to ask if you have analysed the security implications of introducing this exception list since I couldn't find any such discussion on the relevant ticket [3]. So, have you? Personally I reacted on that it is a simple match vs the extension's id, e.g. something we should consider attacker-controlled. I haven't looked at the code closely, but I'd expect attackers can deliver their malicious code in extensions that only need to have that same id as some extension with an exception to completely bypass the code signing check. Think, for instance, about an "upgraded" Torbutton.
Is my above hunch true? If so I think this approach is a bit dangerous: without the "mandatory" part, this code signing adds a false sense of security. IMHO this approach then either has to be improved (e.g. by also matching on a cryptographic hash of the XPI) or dropped and replaced with a different solution. I think it can be argued that just flipping the build switch that disables the extension code signing checks is preferable.
Cheers!
[1] https://labs.riseup.net/code/issues/11419 [2] I tried something really ugly: I adjusted our build script to unpack the two affected omni.ja files and patch in our exceptions, but there are binary versions (e.g. XPIProvider.jsm) generated from the patched files, so this doesn't work (or is there an easy way to re-generate the .jsm files?). [3] https://trac.torproject.org/projects/tor/ticket/14970