Root CAs in Add-ons
Eddy Nigg
installing or updating the extension. I haven't tested it, but some
tweets on Twitter seems to confirm it.
It's not a surprise that this is supposed work without warning the user
and I believe Moxie himself has warned of such a scenario. How does
Mozilla intend to protect the users or at least notify upon such an
attempt to alter the Authorities store? Does this conform to any policy
Mozilla might have in place?
Considering further that Addons are downloaded unsecured and signed
Addons are hardly distinguishable from those that aren't, the security
of the user can be too easily compromised.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Eddy Nigg
Thanks for your response.
On 04/03/2010 12:54 AM, Shawn Wilsher:
> On 4/2/2010 2:34 PM, Eddy Nigg wrote:
>> Apparently Moxie's Google-Sharing addon installs a CA root when
>> installing or updating the extension. I haven't tested it, but some
>> tweets on Twitter seems to confirm it.
> I've sent an e-mail to amo-editors for someone on that team to
> investigate it.
OK
> Since the add-on is hosting AMO I think that behavior would violate
> the "No Surprises" section [1] which is not presently live on the
> policy document [2], but is being enforced.
OK
Are addon developers aware of it?
> Add-ons from AMO are not downloaded unsecured, and we throw up a big
> warning when downloading it from a non-whitelisted site.
I believe that the actual download happens unsecured. For example I just
tried this:
https://addons.mozilla.org/downloads/file/78065/coolpreviews-3.0.1-fx+mz.xpi?src=api
Which in turn redirects for the actual download to:
http://releases.mozilla.org/pub/mozilla.org/addons/2207/coolpreviews-3.0.1-fx+mz.xpi
Now with Non-HTTPS it's possible to redirect further or tamper the
content at will.
> Additionally, you cannot install an add-on without the user explicitly
> opting into it.
>
That's true, but how do I know what I'm installing? Specially when the
download happens in plain text instead over an SSL secured connection?
The vast majority of addons are not signed by the developers.
David E. Ross
> Apparently Moxie's Google-Sharing addon installs a CA root when
> installing or updating the extension. I haven't tested it, but some
> tweets on Twitter seems to confirm it.
>
> It's not a surprise that this is supposed work without warning the user
> and I believe Moxie himself has warned of such a scenario. How does
> Mozilla intend to protect the users or at least notify upon such an
> attempt to alter the Authorities store? Does this conform to any policy
> Mozilla might have in place?
>
> Considering further that Addons are downloaded unsecured and signed
> Addons are hardly distinguishable from those that aren't, the security
> of the user can be too easily compromised.
>
If the root is stored by the extension in the user's certificate
database and not in the read-only NSS database, the capability I
requested in bug #545498 might provide alert users that something is
going awry.
I just now updated that bug report to suggest that the inconsistency
display appear whenever the user's certificate database changes. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=545498>.
On the other hand, if the extension stores the root in the read-only NSS
database, then I would consider this a Critical priority bug.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Eddy Nigg
> On the other hand, if the extension stores the root in the read-only NSS
> database, then I would consider this a Critical priority bug.
>
I believe that it gets installed as a software device and not built-in
root because the NSS root DB is read only. Since there may be many such
software device CA files, it's hard to detected them. Additionally the
root stays also during restart and is not reset as with the built-in roots.
Daniel Veditz
> Apparently Moxie's Google-Sharing addon installs a CA root when
> installing or updating the extension. I haven't tested it, but
> some tweets on Twitter seems to confirm it.
Which tweets? When I searched I couldn't find any except one from
@mozillagroups that pointed back at your post here.
_I_ have tested it, and it does no such thing.
> It's not a surprise that this is supposed work without warning
> the user and I believe Moxie himself has warned of such a
> scenario.
Absolutely not a surprise that extension code could do whatever it
wants, that's why it needs to be reviewed.
> How does Mozilla intend to protect the users or at least notify
> upon such an attempt to alter the Authorities store? Does this
> conform to any policy Mozilla might have in place?
Messing with the cert db probably should get flagged for additional
review in the future just because it's such a sensitive area, but in
this case the initial reviewer was right. Moxie's installing a
self-signed cert for his website and setting the server certificate
trust bit. The cert does happen to have CA bits, but it is not
installed as an authority and the CA trust bits are not turned on.
> Considering further that Addons are downloaded unsecured
They are not insecure (unless you disable JavaScript). The site
serves up a sha256 hash with the install link over SSL, and the
final .xpi is checked against that hash.
If you disable JavaScript then the site can't invoke the install
with a hash. We've got a bug on file to make an install fail if it
redirects from https to http unless it's initiated with a hash.
-Dan Veditz
Daniel Veditz
>> Since the add-on is hosting AMO I think that behavior would violate
>> the "No Surprises" section [1] which is not presently live on the
>> policy document [2], but is being enforced.
If the add-on were installing a root CA it wouldn't just be a
"surprise" it would be an evil MITM tool. As it's just the server
certificate for the proxy that's the main point of the tool there is
no surprise here.
> Are addon developers aware of it?
It being the "no surprise" policy? Many of them are, we've
prominently blogged about it.
> I believe that the actual download happens unsecured. For example I just
> tried this:
>
> https://addons.mozilla.org/downloads/file/78065/coolpreviews-3.0.1-fx+mz.xpi?src=api
>
>
> Which in turn redirects for the actual download to:
>
> http://releases.mozilla.org/pub/mozilla.org/addons/2207/coolpreviews-3.0.1-fx+mz.xpi
Yes, if you load the link directly that's what you get. If you're
using raw links then it's better to use or share an SSL link to the
archive site
https://archive.mozilla.org/pub/mozilla.org/addons/2207/coolpreviews-3.0.1-fx+mz.xpi
Our poor non-mirrored archive can't handle the load if everyone did
that, though. Most people don't need to. On the site the install
would be triggered through JavaScript and the final file, wherever
it happens to come from, will be checked against a sha256 hash.
-Dan Veditz
Eddy Nigg
On 04/03/2010 09:41 AM, Daniel Veditz:
Which tweets? When I searched I couldn't find any except one from @mozillagroups that pointed back at your post here.
InfoTechWerx @moxie__ Just uninstalled GoogleSharing. Your certificate lingers.
moxie__ @InfoTechWerx Yeah, that was the primary motivation for including addon-update hijacking in sslsniff. You can do anything from an addon.
InfoTechWerx @moxie__ Scary.
_I_ have tested it, and it does no such thing.
Absolutely not a surprise that extension code could do whatever it wants, that's why it needs to be reviewed.
They are not insecure (unless you disable JavaScript). The site serves up a sha256 hash with the install link over SSL, and the final .xpi is checked against that hash.
Eddy Nigg
> If the add-on were installing a root CA it wouldn't just be a
> "surprise" it would be an evil MITM tool.
>
Right, and I felt obligated to ask if that's possible and if that's the
case.
Jean-Marc Desperrier
>> _I_ have tested it, and it does no such thing.
> Excellent!
But it could any time Moxie decides to change it to.
AMO could have a jshydra script to test if an extension accesses the
most sensitive parts of the crypto API.
It would not be 100% safe though (you still can include a binary
component, and with eval you probably can work around even a smart
jshydra script).
David E. Ross
> If you disable JavaScript then the site can't invoke the install
> with a hash. We've got a bug on file to make an install fail if it
> redirects from https to http unless it's initiated with a hash.
>
What is the bug number?
Matt McCutchen
> On 4/2/10 10:41 PM, Daniel Veditz wrote [in part]:
> > If you disable JavaScript then the site can't invoke the install
> > with a hash. We've got a bug on file to make an install fail if it
> > redirects from https to http unless it's initiated with a hash.
> >
>
> What is the bug number?
https://bugzilla.mozilla.org/show_bug.cgi?id=310355#c9
--
Matt
Robert Kaiser
> On 03/04/2010 12:50, Eddy Nigg wrote:
>>> _I_ have tested it, and it does no such thing.
>
>> Excellent!
>
> But it could any time Moxie decides to change it to.
How so? Every add-on update must be reviewed before it goes public, and
AFAIK reviewers usually look at the changes done in the code - I hope
they'd catch that.
Robert Kaiser
Philip Chee
AMO has their own MXR for addons where they can inspect the diffs
whenever a new extension version is uploaded.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Daniel Veditz
Sort of, that one's about improving the UI to indicate whether a
hash was used or not. A user who just sees an https URL in the
dialog will feel safe even if there isn't a hash, and won't know
whether there's a redirect or the security implications of that
redirect.
I was thinking of
https://bugzilla.mozilla.org/show_bug.cgi?id=537761