Firefox Extension download process and the mess within

[ Update
The https://bugzilla.mozilla.org/show_bug.cgi?id=544660 bug was reported as fixed.

So where were we and where are we ?

Say I try it now:

ff_aft_1[4]

ff_aft_5[4]

As I commented previously on this blog entry, fixing this bug resolves little.
The above error is not a security warning/error.
If the user queries after it, might end up right here(unofficial Mozilla related web site):
http://kb.mozillazine.org/Unable_to_install_themes_or_extensions_-_Firefox#Invalid_file_hash

According to that entry: Manually install the extension (right-click the install link -> "Save Link As"-> save the .jar or .xpi file, then drag the file icon onto an open Firefox window).

Say I do that(it’s a reasonable explanation, and I’m on the correct web site, using HTTPS) and after I drag the downloaded extension:

ff_aft_6[4]

It’s not hard to guess that I’ve manually downloaded the extension from the “wrong” place(this will happen even if I manually copy and paste the "HTTPS URL" which was a "safe" URL).
Also is not hard to guess what will follow when I hit Install Now above.

Mozilla’s very own take over that error:
This error message may be caused when you have Firefox set not to allow third-party cookies. To prevent this error, you need to temporarily enable third-party cookies.

]

[ Update
Giorgio Maone has filed a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=544660 ]

This is something that I’ve discussed a while ago with Ivan Ristic.

Say you go to https://addons.mozilla.org and download a popular extension. Maybe NoScript. The download location appears to be over HTTPS.

ff_ext_silly_8

But not quite.
If we take a look:

  • A request is used to search for the latest version. The location of this (latest) version is indicated with a 302 response(it has an https:// in front).

ff_ext_silly_5

  • now it searches for the specific version(over HTTPS), as instructed previously with the 302 response. And another 302 response(this time it has just a http:// in front) indicates the location of the file.

ff_ext_silly_6

  • and so the actual extension download happens over plain HTTP, although visually you have the impression that this is done over HTTPS.

ff_ext_silly_7

This related bug hints at the possibility of having the extension download happening over HTTP and a file hash to be sent over HTTPS, which seem fairly reasonable.
However, it’s not clear what exactly happens(hence the mess word from the title of this blog post). Asking on that bug page seems to be a waste of time.

Edited to add
[Giorgio Maone commented that the hash is embedded in the download page. I was looking for it in the wrong place. Thanks Giorgio for the correction.

ff_ext_silly_13

The modified extension’s hash:

ff_ext_silly_14

Still, in my tests, this changes nothing to what is listed bellow for the default installation of Firefox 3.6 and 3.5.7(tried that today).

It only fails by default when I attempt to add the extension from the Add-ons pop-up window:

]

Today I had some time, so I’ve decided to play a little with this.

Test plan:
- a test VM using Windows XP SP3(I already have it in my lab), on which Firefox 3.6 will be installed. Snap Shots were used, to revert the machine to a clean state and re-test.
- a test web server holding my version of NoScript, initial test: instead I used the Adblock extension simply renaming the file.
- analyze the current location of NoScript. Which was: http://releases.mozilla.org/pub/mozilla.org/addons/722/noscript-1.9.9.45-fx+sm+fn.xpi
- on the VM using Windows XP SP3 we need to simulate somehow an environment where an attacker has access to the wire. The simplest trick is to use DNS for that and have the client resolving releases.mozilla.org to my web site. Editing the hosts file on the client did the trick.
- so the client will download the extension over HTTP from my web site, while keeping the green of the EV certificate visible to the user.

Let’s see what happens.
Navigate to https://addons.mozilla.org and attempt to Add to Firefox NoScript. This is a blind test. I’m not interfering except with the DNS trick.

ff_ext_silly_1

Well, Wladimir Palant is now the author of NoScript, and of course, I’m downloading it over HTTPS.

ff_ext_silly_2

Hit install, and things went fine, it tells me that Adblock was installed and to restart Firefox:

ff_ext_silly_3

I do that, and the confirmation:

ff_ext_silly_4

At this point, the extension download process tends to become amusing.

What happens if we modify the original NoScript extension, say have it to start NoScript with allow scripts globally by default.

Did that, re-test on a clean machine:

ff_ext_silly_10

Click install and:

ff_ext_silly_9_inv

So are they using a hash after all ?
Then, why I was able to install Adblock instead of NoScript. Maybe they did not bind things properly.
Need a re-test.

Re-tested(rebooted my web site in the process), and it worked this time(looks like a misfire from my lab), without any major warnings.

ff_ext_silly_11

Re-tested a couple of time, and success every time.

Wow!

Following Ivan’s suggestion to see what’s inside that SSL traffic, I’ve used Burp Proxy, made it use a custom certificate with SAN DNS Names fields, made Firefox trust the CA that issued this certificate, so that we will not get any warnings if either services.addons.mozilla.org or addons.mozilla.org or are used as destinations.

Tested again, and success one more time. Quickly looking at the history on Burp Proxy, and I could not spot any hash whatsoever(see the above within the edited section).

Assuming I’m not rusty, and missed something, this is not quite a safe way of downloading and installing an extension(politely saying that).

Ivan Ristic also hinted that the Submitting an add-on to AMO document is not clear if whether updates are also reviewed or not.

On a side note, they seem to do extension version checks update over HTTPS, this was spotted on my laptop:

ff_ext_silly_12

Comments (14) -

  • The hash is embedded in the download page and used only if you've got JavaScript enabled for addons.mozilla.org. You won't see it in the "download click" traffic because it's already been provided by the page markup.
  • Giorgio, the tests were performed with a default installation of Firefox 3.6, that is: a clean XP VM, install Firefox and then add an extension to it, so I did not modify anything to Firefox, just the way it was.

    Further more, visually there is no aid in understanding what is happening in the background, the topic of the mentioned (old) bug.

    Thanks,
    Adrian
  • I've updated the blog entry to reflect Giorgio's comment about the hash location.
  • It fails by defult when I try to add the extension from the Add-ons pop-up window. Edited the blog entry to reflect this.
  • Looks like AMO developers broke their install button during some cosmetic "revamp": neither the add-on icons nor the crypto hashes are working anymore, and this is surely unintentional because the code to support them is still there.
    I'm filing a bug report, and hope to have it fixed ASAP.
  • thanks Giorgio for the input.

    I will update the blog entry when something new appears.
  • Filed bugzilla.mozilla.org/show_bug.cgi?id=544660.

    Notice that since NoScript's XPI is itself cryptographically signed, security-conscious users should always check that the install box says "NoScript (InformAction)" like in your first screenshot.
    Seeing a different author (Wladimir Palant) or, worse, "Author not verified" should trigger a red alert.

    But I agree that regular Joe won't watch this very carefully. Maybe signature info should be more prominent in the UI,  and so a warning if the hash was missing while  the HTTP channel was not secure (like in this case).
  • Updated the blog entry to reflect that a bug was opened for this issue.
  • In the future, please report security bugs in Bugzilla or by email (addons.mozilla.org/.../contact) rather than publicly exposing these issues and making us rush to fix the problem before someone takes advantage of it. Thanks.
    • Justin, I've considered this.

      However, looking at Bug 310355(and its lack of attention), this not seem appropriately.

      Further more, Bug 544660 is just a side effect of this blog entry. Fixing it now really means pretty much nothing to ends users and to the client side, as it can be easily reintroduced, and the whole process is too "transparent"(in  a bad way) to users and to the client side.
      Bug 544660 would not have been such of a problem if Bug 310355 would have been treated with more attention.

      Thanks,
      Adrian
  • The question I would ask is this:  if the contract conditions of using an EV SSL certificate specified you had to do the entire website under EV, would Mozilla still have used the EV certificate?

    It doesn't seem entirely credible that Mozilla would use an EV certificate for downloading of web browser plugins.  But let's say that this is reasonable;  if it is, if this is a reasonable thing to do, then wouldn't a reasonable trade for the apparent security message of the green bar have been some higher security requirements on the website?  Such as downloads over EV as well?
    • Doing an entire web site over EV is a relative thing.

      For example, one can "actively" load content only from the EV site.
      But that does not mean it cannot link to other web sites, including plain HTTP ones.

      In the addon-ons context, it can simply link to https://anotherwebsite/extension_1, etc., which does not have to be an EV site.
      Or just link to http://anotherwebsite/extension_1.
      The explanation would be that this is a diffrent web site or whatever. And is your action(click on the link) that take you there. Further more, the link does not have to say 'download', just visit extension or whatever, and trigger a pop-up window.
      Or the download can be signed, so they would need no explanations.

      As a side note, just look at Hotmail, it has an "Enhanced Security" button, if you click that, it takes the login over EV cert, once you login where it takes you ?
      They can claim it's like that to protect your login crendentials and to assure you that indeed you are connected to login.live.com. It's not necessarily to use that EV cert to protect the messages or whatever you view after the login.

      It can be forced the showing of a warning when leaving the EV site, but this may sound counter productive.

      The EV cert is only assuring you of the identity of the web site you access, not of the ones where this site may take you. Even if you asses(enhance) the security of the EV web site, same will not be true for the linked web sites.

      The credibility of the psoibility of using an EV cert for the actual process of downloading extensions is irrelevant IMHO in the context of 99% of the users, for the very reason they will not wonder in the first place.
      The "green" only provides for some of them the "peace of mind" they are on the web site they wanted to visit.

      Thanks,
      Adrian
  • w
    Thank you for all your blogs.

Pingbacks and trackbacks (1)+

Comments are closed