Firefox addon security question
EricLaw
pulls in a remote script via HTTP:
e.g. inside firefoxOverlay.xul:
<script src="http://example.com/extensions/script.js?ff"/>
...is that script accorded the permissions of the chrome:// security
zone? If so, that can enable a remote EoP if there's a MiTM attack,
right?
Thanks!
-Eric
Boris Zbarsky
> Quick question for you� When a XUL file in an installed Firefox addon
> pulls in a remote script via HTTP:
>
> e.g. inside firefoxOverlay.xul:
>
> <script src="http://example.com/extensions/script.js?ff"/>
>
> ...is that script accorded the permissions of the chrome:// security
> zone?
Yes.
> If so, that can enable a remote EoP if there's a MiTM attack, right?
Yes. Don't do that.
-Boris
Sid Stamm
big-time.
https://addons.mozilla.org/en-US/developers/docs/policies/reviews
In fact, it is prohibited for an add-on hosted by addons.mozilla.org to
fetch remote content in this way, falling into the prohibited add-on
category of "Add-ons that provide their own update mechanism for
chrome-privileged resources" (see above link and below one).
https://developer.mozilla.org/en/Security_best_practices_in_extensions#Remote_JavaScript_and_Content
A safer way to run remote scripts is to call "evalInSandbox" on the URL
for the code, giving it restricted access (i.e., not chrome privileges),
so it can still be run to do some things, but not to play with chrome
stuff.
-Sid
EricLaw
Is there somewhere "official" that extensions that do this should be
reported?
thanks,
Eric
On Dec 18, 2:32 pm, Sid Stamm <s...@mozilla.com> wrote:
> Like Boris says, JavaScript in add-ons is bad, and it is frowned upon
> big-time.
>
> https://addons.mozilla.org/en-US/developers/docs/policies/reviews
>
> In fact, it is prohibited for an add-on hosted by addons.mozilla.org to
> fetch remote content in this way, falling into the prohibited add-on
> category of "Add-ons that provide their own update mechanism for
> chrome-privileged resources" (see above link and below one).
>
> https://developer.mozilla.org/en/Security_best_practices_in_extension...
>
> A safer way to run remote scripts is to call "evalInSandbox" on the URL
> for the code, giving it restricted access (i.e., not chrome privileges),
> so it can still be run to do some things, but not to play with chrome
> stuff.
>
> -Sid
>
> On 12/18/09 2:10 PM, Boris Zbarsky wrote:
>
>
>
> > On 12/18/09 1:44 PM, EricLaw wrote:
> >> Quick question for you… When a XUL file in an installed Firefox addon
> >> pulls in a remote script via HTTP:
>
> >> e.g. inside firefoxOverlay.xul:
>
> >> <script src="http://example.com/extensions/script.js?ff"/>
>
> >> ...is that script accorded the permissions of the chrome:// security
> >> zone?
>
> > Yes.
>
> >> If so, that can enable a remote EoP if there's a MiTM attack, right?
>
> > Yes. Don't do that.
>
> > -Boris- Hide quoted text -
>
> - Show quoted text -
Adrienne Porter Felt
can get the dev to fix it. Some devs are willing to fix security bugs like
this immediately.
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Daniel Veditz
> Thanks for confirming, all!
>
> Is there somewhere "official" that extensions that do this should be
> reported?
>
> thanks,
> Eric
secu...@mozilla.org functions as an overall contact address for any
security concern related to the Mozilla project. If it's not in code
we're directly responsible for we will track down and work with the authors.
If the addon is hosted at Addons.mozilla.org you could also mail
amo-admins at mozilla.org in addition, or if you prefer you could also
file a bug at https://bugzilla.mozilla.org in the Product
"addons.mozilla.org" and Component "Add-on Security", but be sure to
check the "This is a security problem" checkbox so it sets off the alarm
bells.
If the add-on was not hosted on AMO then just mail the general security
address and we'll figure it out.