headers
Mook | 1 Dec 2009 08:05

Re: Safety of extensions (DefCon presentation)

Devdatta wrote:
>> 3) One of the things we found in our study (which Adrienne has made
>> public at <http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-139.pdf>)
>> is that many extensions use nsIFile to store extension-local
>> persistent state.  You might consider providing an alternative API
>> (e.g., something like localStorage) that lets Jetpacks store
>> persistent state without the authority to read and write arbitrary
>> files.
> 
> The study says that extensions use nsIFile to 'store information that
> is too complex for the preferences system'. What is 'too complex' ? If
> a key value store (viz. the preferences system) isn't good enough,
> would localStorage work ? Do you have a list of extensions for whom
> localStorage would be good enough (but can't work with just the
> preferences system) ?
> 

For non-Jetpack extensions, places like #extdev have been explicitly 
telling people to avoid prefs for larger scale storage, because prefs 
are always completely loaded on startup (so things like a table for a 
site-specific extension wouldn't make sense.  localStorage would work, 
but then again the extensions could already access the sqlite storage 
(https://developer.mozilla.org/en/Storage) stuff anyway.

(I must be odd, since about half my extensions don't interact with the 
content page being viewed, and I don't think any of them is doable with 
the current Jetpack API...)

--

-- 
Mook
(Continue reading)

Permalink | Reply | 1 comment |
headers
Devdatta | 1 Dec 2009 09:13
Picon
Gravatar

Re: Safety of extensions (DefCon presentation)

>
> For non-Jetpack extensions, places like #extdev have been explicitly telling
> people to avoid prefs for larger scale storage, because prefs are always

ohh! Makes sense!

> completely loaded on startup (so things like a table for a site-specific
> extension wouldn't make sense.  localStorage would work, but then again the
> extensions could already access the sqlite storage
> (https://developer.mozilla.org/en/Storage) stuff anyway.

The SQLlite stuff uses nsIFile. The problem is that nsIFile allows
arbitrary access to any file, which is not good. I don't want every
extension I install to have the power to delete all my documents. You
ideally want to limit the privileges of an extension to the minimum
(Principle of Least Privilege).

To me, it looks like (and I might be wrong here), there are two
obvious/simple ways to do it :
   * Limit nsIfile to only write to files in a particular directory
(say specific to each extension).
   * Make extension writers use stuff like localStorage and
disallow/discourage use of nsIFile.
(is there any other option I have missed?)

(There are ofcourse extensions that might require arbitrary file
access, but for them AMO could require intensive review )
I am a fan of option 1.

Mook : As an extension developer, what problems do you see with either
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mook | 2 Dec 2009 06:57

Re: Safety of extensions (DefCon presentation)

Devdatta wrote:

> To me, it looks like (and I might be wrong here), there are two
> obvious/simple ways to do it :
>    * Limit nsIfile to only write to files in a particular directory
> (say specific to each extension).
This would cover quite a bit, actually; most things really just want to 
stick some persistent data _somewhere_, not anywhere in particular.  As 
an extension developer who really just wants stuff to keep working with 
the minimum effort, of course this is my preferred option - well, next 
to having no restrictions of course ;)

>    * Make extension writers use stuff like localStorage and
> disallow/discourage use of nsIFile.
This would cover a smaller subset of the above - it wouldn't be useful 
for things like greasemonkey (multiple files), but might be for, say, 
adblockplus (giant list of things).  This of course assumes that each 
extension gets its own localStorage space, since enumeration is used 
quite often too.

> (is there any other option I have missed?)
For completeness, there's also one sqlite db per extension which can go 
create as many tables as it wants).  Possibly also free access to the 
profile, but not outside of it, but given that the list of extensions is 
there too it's uncertain how useful that is.

> (There are ofcourse extensions that might require arbitrary file
> access, but for them AMO could require intensive review )
> I am a fan of option 1.
As long as it's opt-in, yes, that should be fine.  I've always
(Continue reading)

Permalink | Reply | 1 comment |
headers
Devdatta | 2 Dec 2009 08:33
Picon
Gravatar

Re: Safety of extensions (DefCon presentation)

>
> This would cover quite a bit, actually; most things really just want to
> stick some persistent data _somewhere_, not anywhere in particular.  As an

There are two related properties we are talking about here :
1. Most extensions can survive with just nsIFile access to a (their
own) particular folder
2. Currently most extensions only use nsIFile to access things in
their own folder anyway.

From what I read, you said 1. is true. I am also interested in knowing
about the second. Do you have any idea about the second property
through your involvement in the AMO/extdev community ?

Cheers
Devdatta
Permalink | Reply | 0 comments |
headers
EricLaw | 18 Dec 2009 22:44
Picon

Firefox addon security question

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?  If so, that can enable a remote EoP if there's a MiTM attack,
right?

Thanks!

-Eric
Permalink | Reply | 5 comments |
headers
Boris Zbarsky | 18 Dec 2009 23:10
Picon
Favicon

Re: Firefox addon security question

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
Permalink | Reply | 4 comments |
headers
Sid Stamm | 18 Dec 2009 23:32

Re: Firefox addon security question

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_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

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?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon723 | 21 Dec 2009 04:16
Picon

FF3 ssl_error_internal_error_alert with SSL cert issued from known CA


I have a web application running on Tomcat5 (installed on a RHLE OS).
I have installed a Network Solutions issued SSL cert in my keystore.
While my application can be accessed fine with IE, Safari, and FF2.
FF3 will keep reporting "ssl_error_internal_error_alert".  I have
installed all the certs issued by the CA in the correct order, but FF3
still keeps reporting the below error.  Tomcat is configured to
operate in TLS. I have tried to change it to SSL but that still does
not work.    A large portion of our user base use FF3 as their web-
client to access our application.  I have even created a new keystore
and had the CA re-issue me the certs - still didn't help. My certs are
valid do not expire any time soon.

Can any FF guru please help? Some link / cookbook / instructions would
be very much appreciated.

Thank you much.

URL:   https://evantage.trustetc.com/eVantage
Error in FF3:

Secure Connection Failed

An error occurred during a connection to evantage.trustetc.com.

Peer reports it experienced an internal error.

(Error code: ssl_error_internal_error_alert)

    *   The page you are trying to view can not be shown because the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nelson Bolyard | 21 Dec 2009 10:50

Re: FF3 ssl_error_internal_error_alert with SSL cert issued from known CA

On 2009-12-20 19:16 PST, Simon723 wrote:
> I have a web application running on Tomcat5 (installed on a RHLE OS). I 
> have installed a Network Solutions issued SSL cert in my keystore. While 
> my application can be accessed fine with IE, Safari, and FF2. FF3 will 
> keep reporting "ssl_error_internal_error_alert".

Your TomCat server is sending a TLS error message, known as an alert,
to Firefox, reporting that it (TomCat) had an internal error.
Firefox is merely reporting that to the user.
Firefox can't do anything about it except report it to the user.
It's not an error in Firefox.  It's an error in TomCat.

> I have installed all the certs issued by the CA in the correct order,
> but FF3 still keeps reporting the below error.  Tomcat is configured to 
> operate in TLS. I have tried to change it to SSL but that still does not 
> work. A large portion of our user base use FF3 as their web-client to 
> access our application.  I have even created a new keystore and had the 
> CA re-issue me the certs - still didn't help. My certs are valid do not 
> expire any time soon.

You seem to be assuming that the problem is related to your certificates.
I see no evidence that this is so.  Firefox isn't complaining about your
server certificates.  Firefox isn't complaining about your server at all.
Your server is complaining about itself!

> Can any FF guru please help?

You need a TomCat guru.

> Some link / cookbook / instructions would be very much appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
EricLaw | 21 Dec 2009 21:15
Picon

Re: Firefox addon security question

Thanks for confirming, all!

Is there somewhere "official" that extensions that do this should be
reported?

thanks,
Eric

On Dec 18, 2:32 pm, Sid Stamm <s... <at> 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:
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane