Georg Koppen:
anonym:
[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]
Hm. I have not thought about having a different method for setting up a whitelist, so, maybe?
"Maybe" as in "patches welcome"? :P Or is there something you find problematic with this whole idea?
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.
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.
~~
I'd also like to ask if you have analysed the security implications of introducing this exception list [...]
[...]
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.
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
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).
Agreed!
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. """
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!