TBB vs mandatory extension signing
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
anonym:
I think it can be argued that just flipping the build switch that disables the extension code signing checks is preferable.
Actually, I just tested a nightly build from today, and setting pref("xpinstall.signatures.required", false); still allows our two unsigned extensions to be loaded (but with the warning) and they work as expected. Is this because tor-browser-52.0.2esr-7.0-2 is based on a development branch of Firefox? I.e. I cannot rely on this being the case when TBB 7.0 is released, right? Cheers!
[This is a repost of my full original post. It contains a line consisting only of "--" which makes some MUA:s think "ah, the rest is a signature, let's hide it".] 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
anonym:
Hm. I have not thought about having a different method for setting up a whitelist, so, maybe? Regarding your [2]: the binary files are just optimizations. You can delete the respective file(s) and the uncompressed one(s) will be used. That should have a tiny performance impact but that might be negligible in your case.
We have looked into that but have not written anything down that can be found easily. I guess a good place for that would be our design document. In fact I just have opened #21XXX to get that spec updated, thanks. Regarding your question it is first important to see that we have need extensions not signed by Mozilla. We could have a discussion about whether we should get Torbutton and TorLauncher signed by Mozilla and just require XPI-signing everywhere. But that would be a different one than the one in this mail and I am not convinced the benefits outweigh the risks. So, what do we do? It seems to me we have 3 possible ways to deal with that 1) Disable the XPI-signing requirement globally 2) Ship a narrow whitelist 3) Deploy our own extension signing infrastructure 3) seemed to us pretty invasive back then but I am fine thinking harder about it if we come to the conclusion that no other option strikes a proper benefit/risk balance. Before going to discuss 2) and 1) lets differentiate between a local attacker who can do things on your machine and an attacker on the network (I am not sure if you had both or just one of them in mind when you used "attacker" above). A local attacker is out of scope for this I think. Because extension signing would not help against one. They could just modify your firefox binary and you are hosed or they can deploy temporary extensions which do not require signing (at least not in the ESR45 series). That leaves the network attacker. Here is what I wrote to some Mozilla folks that claimed back then our code-signing exemption does not buy us anything: """ First of all I think it is not true that we don't get any benefit of all by the way the exemption is written. The main benefit is that users can't download and install any [random, G.K.] unsigned extension. They even can't get loaded them from the harddisk or any other local storage device [by just dragging them over to Tor Browser, G.K.]. Note, this includes *the extensions we exempted from the signing requirement as well* [emphasis mine, G.K]. A second benefit is that the patch is pretty small trying to minimize possible disruption in a sensitive area. As to the social engineering risks. Yes, there have always been social engineering risks around malicious extensions and while reducing them drastically the patch does not completely eliminate them. An attacker needs to convince a user to overwrite one of our extensions manually in order to win which is an highly unusual request and many users probably don't even know where their extensions folder is. But, yes, as said there is still a risk left. """ Note that you are worse off if you are just flipping the preference. Oh, and there are other extensions that already poked a hole in the extension signing requirement: temporary and system extensions (for the former see e.g. https://blog.mozilla.org/addons/2015/12/23/loading-temporary-add-ons/). It seems to me that the social engineering risks that still apply to our approach apply to this kind of extensions as well. Georg
Georg Koppen:
"Maybe" as in "patches welcome"? :P Or is there something you find problematic with this whole idea?
What do you mean with "uncompressed one(s)"? In my attempt of [2] I removed the affected .jsm files inside the omni.ja archives, hoping that the pure .js ones would be used (with a negligible performance hit), but when I tried starting Tor Browser I got tons of errors logged to stderr, no add-ons were loaded, abd the add-on manager only showed the "Get add-ons" tab. I might have done something wrong, so I'll retry once I've gotten your clarification. Note that in Tails the Tor Browser directory is not writeable by the user running Tor Browser (only the profile directory is) which might influence this e.g. if Tor Browser would like to write uncompressed .jsm files into the Tor Browser directory.
We are in the same boat; we generate one of our extension dynamically at Tails build time, so signing it would be problematic (there are solutions, but we'd rather not go that way).
[...] (I am not sure if you had both or just one of them in mind when you used "attacker" above).
I left that deliberately unclear, because it was not clear to me whether your patches would affect
Agreed!
This was exactly what I was hoping to hear: the white-list only affects *already installed* add-ons, so Tor Browser itself will never be able to fetch + install + load unsigned extension code, not even if spoofing as one of the white-listed add-ons; the only attack vector is to socially engineer the user to overwrite one of the white-listed exceptions in the file system using some external (i.e. non-Tor Browser) means. [1] Great! [1] Well, the Tor Browser's file dialog could be used to overwrite an extension, but that is beside the point I'm trying to make: none of the intended ways to install/upgrade add-ons can be used, and that is what matters. Cheers!
anonym:
I am not so happy with the external file idea. Maybe having a preference would be enough? In general, I like to avoid complexity in this particular area but if there is no other way to keep Tails working I think we would take a patch.
That's what I meant. I've been working with this method for a while now when I need to modify js stuff related to the Firefox front-end side as this is the fasted way to test changes. I had no issues so far. Note that with 7.0a3 there should be no compressed JS code modules etc. in omni.ja files anymore. See: https://trac.torproject.org/projects/tor/ticket/21960 and the linked Mozilla bug for further details. We are currently doing the hopefully final -build5 and the 7.0a3 we give out should have it. [snip] Georg
On 4/11/17 11:59 AM, anonym wrote:
I think that xpinstall.signatures.required still works in Firefox 52 ESR although I have not been able to find where it is documented. Maybe someone who is on this list else knows.
Georg can answer better than me, but the main reason we enable the signing check is to protect users who they try to install extensions that we do not bundle with Tor Browser. It should be difficult for an attacker to replace the extensions for which we include exceptions with their own code: updates are disabled for Tor Launcher and Torbutton, and HTTPS-E updates are protected by the updateKey mechanism (https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#updateKey). -- Mark Smith Pearl Crescent http://pearlcrescent.com/
participants (3)
-
anonym -
Georg Koppen -
Mark Smith