Safety of extensions (DefCon presentation)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Safety of extensions (DefCon presentation)

KAMI911 KAMI911
Hello!


Today, one of leading IT portal published an article about FIrefox with
this title: "Firefox is not safety because of its extensions". The
article concludes the findings of this published article:

https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-roberto_liverani-nick_freeman-abusing_firefox.pdf
that was released at DefCon (https://www.defcon.org/)

What do you think about this presentation? Do we have official answer?
Do you have opinions about risks, best practices, advices?


If this is not a good list for this question, I am really sorry, and
please forward my letter to the right lis and notify me.

Thank you in advance!


--


Best regards,

KAMI

Hungarian Mozilla Community member


Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com

My projects: http://ooop.sf.net/ | http://hun.sf.net/

Blog (Hun): http://bit.ly/10ucTR | Donate: http://bit.ly/eYZO6

Follow me: http://bit.ly/gJuJZ | http://bit.ly/kDocB



_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Gervase Markham
On 25/11/09 18:47, Kálmán „KAMI” Szalai wrote:
> Today, one of leading IT portal published an article about FIrefox with
> this title: "Firefox is not safety because of its extensions".

That's like saying "Windows is not safe because of applications".

Installing an extension is like installing an application on your
machine - it's just as trusted as any other application.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

ianG-2
On 26/11/2009 15:35, Gervase Markham wrote:
> On 25/11/09 18:47, Kálmán „KAMI” Szalai wrote:
>> Today, one of leading IT portal published an article about FIrefox with
>> this title: "Firefox is not safety because of its extensions".
>
> That's like saying "Windows is not safe because of applications".


Or, "SSL has been breached because of phishing" ;)

It is true that to the technical mind that can unravel these things,
these are different things, but to the general public these can often
become the same one thing.  So when they blame the big brand, they might
be wrong or innacurate or just plain confused.  Or they might have been
deceived, and now the deception is coming back to bite.

But the problem still exists.  At a minimum, those protecting the big
brand will need to think about how to distance their brand from the
various not-so-clear things or utter slanders thrown at them.

And those who are concerned about security will know what happens next:
  because each side now has a convenient excuse to blame someone else
for the problem, nothing will be done, and slowly the brand will acquire
a well-deserved reputation for being insecure.  Seen it all before...



In thinking about extensions, one would think that providing a portal
for "friendly extensions" and dealing with only signed or otherwise
checked sources would be sufficient.  Is there a sense that these
techniques aren't working?

Or is the problem out in the wild wild west where users are just
downloading any old shlock?


> Installing an extension is like installing an application on your
> machine - it's just as trusted as any other application.


Right.  Having said that, how does one give the users the tools to
figure that out?  Or is it the users' responsibility to figure it out by
themselves?

To some extent this is the same dilemma the banks find themselves in.
They were forced to use the platform, against good advice, and now find
the platform is biting them.  What to do?  They can't go back.  And
there is no easy forward.



iang
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Adam Barth-8
Jetpack is an opportunity to rethink the extension security model.
Ideally, an extension platform would make it easier for developers to
write secure extensions.  I'm happy to discuss ideas with folks
off-list.

Adam


On Thu, Nov 26, 2009 at 10:01 AM, Ian G <[hidden email]> wrote:

> On 26/11/2009 15:35, Gervase Markham wrote:
>>
>> On 25/11/09 18:47, Kálmán „KAMI” Szalai wrote:
>>>
>>> Today, one of leading IT portal published an article about FIrefox with
>>> this title: "Firefox is not safety because of its extensions".
>>
>> That's like saying "Windows is not safe because of applications".
>
>
> Or, "SSL has been breached because of phishing" ;)
>
> It is true that to the technical mind that can unravel these things, these
> are different things, but to the general public these can often become the
> same one thing.  So when they blame the big brand, they might be wrong or
> innacurate or just plain confused.  Or they might have been deceived, and
> now the deception is coming back to bite.
>
> But the problem still exists.  At a minimum, those protecting the big brand
> will need to think about how to distance their brand from the various
> not-so-clear things or utter slanders thrown at them.
>
> And those who are concerned about security will know what happens next:
>  because each side now has a convenient excuse to blame someone else for the
> problem, nothing will be done, and slowly the brand will acquire a
> well-deserved reputation for being insecure.  Seen it all before...
>
>
>
> In thinking about extensions, one would think that providing a portal for
> "friendly extensions" and dealing with only signed or otherwise checked
> sources would be sufficient.  Is there a sense that these techniques aren't
> working?
>
> Or is the problem out in the wild wild west where users are just downloading
> any old shlock?
>
>
>> Installing an extension is like installing an application on your
>> machine - it's just as trusted as any other application.
>
>
> Right.  Having said that, how does one give the users the tools to figure
> that out?  Or is it the users' responsibility to figure it out by
> themselves?
>
> To some extent this is the same dilemma the banks find themselves in. They
> were forced to use the platform, against good advice, and now find the
> platform is biting them.  What to do?  They can't go back.  And there is no
> easy forward.
>
>
>
> iang
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Gervase Markham
In reply to this post by ianG-2
On 26/11/09 20:32, Adam Barth wrote:
> Jetpack is an opportunity to rethink the extension security model.
> Ideally, an extension platform would make it easier for developers to
> write secure extensions.  I'm happy to discuss ideas with folks
> off-list.

Why off-list? This is mozilla.dev.security :-)

Every sandbox/restricted permissions system, from Java to Android apps,
ends up having to have a way for apps to ask permission to have certain
capabilities. And you get the inevitable problem that users just say
"yes", because they want the app to work. Your video player needs access
to your phonebook? What are you going to do if that seems odd - not
watch videos?

Similarly, there will be Jetpacks which work with your password store
and those which don't. How do you deal with that? Just let all Jetpacks
read the password store? Or have a permissions model? If you have one,
what's to stop users just clicking "Yes"?

The only solution to this problem, IMO, is to authenticate authors, not
code. If you know who the author is, to a sufficient level that there's
some chance of a policeman feeling his collar if he turns out to have
written code which steals all your passwords, then there's an incentive
for good behaviour. (This is how EV SSL certs work.) Of course, this
works against "anyone can author an add-on and put it on the web and
have people use it"...

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Adam Barth-8
On Fri, Nov 27, 2009 at 2:39 AM, Gervase Markham <[hidden email]> wrote:
> On 26/11/09 20:32, Adam Barth wrote:
>>
>> Jetpack is an opportunity to rethink the extension security model.
>> Ideally, an extension platform would make it easier for developers to
>> write secure extensions.  I'm happy to discuss ideas with folks
>> off-list.
>
> Why off-list? This is mozilla.dev.security :-)

I have a bunch of data in a not-yet-published paper that I'm not ready
to release publicly, but we can talk in general first and I can follow
up with the data in a bit after I polish up the paper.

> Every sandbox/restricted permissions system, from Java to Android apps, ends
> up having to have a way for apps to ask permission to have certain
> capabilities. And you get the inevitable problem that users just say "yes",
> because they want the app to work. Your video player needs access to your
> phonebook? What are you going to do if that seems odd - not watch videos?
>
> Similarly, there will be Jetpacks which work with your password store and
> those which don't. How do you deal with that? Just let all Jetpacks read the
> password store? Or have a permissions model? If you have one, what's to stop
> users just clicking "Yes"?

It's important to separate two concerns:

1) Malicious extensions
2) Honest extensions that have vulnerabilities (benign-but-buggy)

I agree that the malicious extension problem is somewhat intractable
because of the above concerns.  However, than news article is
complaining about vulnerabilities in honest extensions.

In the current extension system, any vulnerability in an extension is
disaster because every extension runs with the user's full authority.
That means if I XSS an extension, I can run arbitrary code on your
machine.  In the DefCon talk, the presenters make this clear by
installing VNC and remotely moving the user's mouse.

A fortunate fact of the world is that the vast majority of Firefox
extensions do not require the user's full authority.  (That is the
statement I have a bunch of data to back up.)  If the extension
ecosystem let authors restrict the privileges of their extensions (and
encouraged them to do so), then vulnerabilities in extensions would be
less severe because the attacker would obtain less that the user's
full authority by compromising an extension.

> The only solution to this problem, IMO, is to authenticate authors, not
> code. If you know who the author is, to a sufficient level that there's some
> chance of a policeman feeling his collar if he turns out to have written
> code which steals all your passwords, then there's an incentive for good
> behaviour. (This is how EV SSL certs work.) Of course, this works against
> "anyone can author an add-on and put it on the web and have people use
> it"...

For the benign-but-buggy threat, the authors are perfectly nice
people.  No amount of authenticating them is going to reduce the
severity of vulnerabilities in their extensions.

Adam
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Eddy Nigg (StartCom Ltd.)
In reply to this post by Gervase Markham
On 11/27/2009 12:39 PM, Gervase Markham:
> Similarly, there will be Jetpacks which work with your password store
> and those which don't. How do you deal with that? Just let all
> Jetpacks read the password store? Or have a permissions model? If you
> have one, what's to stop users just clicking "Yes"?

Regarding the above specific example I believe it IS about code and not
author. Access to the password store must happen in the same manner as
Firefox implements it, e.g. poke for the master password every time this
happens.

>
> The only solution to this problem, IMO, is to authenticate authors,
> not code. If you know who the author is, to a sufficient level that
> there's some chance of a policeman feeling his collar if he turns out
> to have written code which steals all your passwords, then there's an
> incentive for good behaviour. (This is how EV SSL certs work.) Of
> course, this works against "anyone can author an add-on and put it on
> the web and have people use it"...
>

As such, this is what code signing certificates really provide and
obviously I'd support that ;-)

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

KAMI911 KAMI911
In reply to this post by ianG-2


Ian G írta:
>
> In thinking about extensions, one would think that providing a portal
> for "friendly extensions" and dealing with only signed or otherwise
> checked sources would be sufficient.  Is there a sense that these
> techniques aren't working?
>
> Or is the problem out in the wild wild west where users are just
> downloading any old shlock?
Do we have friendly extension, or signed extension? Could you describe
the validation process. Is it a go not go test or a detailed code
review? Are there possibility that author create a good extension and
change it for the 4th release to bad extension? Will we have a
bugtracker to follow the possible (security) bugs in the extensions. Can
we introduce "it is safe" tag for the really tested extensions?

>
>
>> Installing an extension is like installing an application on your
>> machine - it's just as trusted as any other application.
>
>
> Right.  Having said that, how does one give the users the tools to
> figure that out?  Or is it the users' responsibility to figure it out
> by themselves?
>
> To some extent this is the same dilemma the banks find themselves in.
> They were forced to use the platform, against good advice, and now
> find the platform is biting them.  What to do?  They can't go back.
> And there is no easy forward.
>
Yes, for example the extension can steal the keystrokes? Should I
netbanking only in safe mode of Firefox?
>
>
> iang
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security

--


Best regards,

KAMI


Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com

My projects: http://ooop.sf.net/ | http://hun.sf.net/

Blog (Hun): http://bit.ly/10ucTR | Donate: http://bit.ly/eYZO6

Follow me: http://bit.ly/gJuJZ | http://bit.ly/kDocB



_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

KAMI911 KAMI911
In reply to this post by Adam Barth-8
Hi!


Adam Barth írta:

>
> It's important to separate two concerns:
>
> 1) Malicious extensions
> 2) Honest extensions that have vulnerabilities (benign-but-buggy)
>
> I agree that the malicious extension problem is somewhat intractable
> because of the above concerns.  However, than news article is
> complaining about vulnerabilities in honest extensions.
>  
And How can we avoid the Malicious extensions problems'. I think the
general user not able to select the right extension. Many users install
spy programs because the read a webpage, or get a false antivirus
notification. How can we protect users if they want to install
extensions mainly one Malicious extension.


--


Best regards,

KAMI


Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com

My projects: http://ooop.sf.net/ | http://hun.sf.net/

Blog (Hun): http://bit.ly/10ucTR | Donate: http://bit.ly/eYZO6

Follow me: http://bit.ly/gJuJZ | http://bit.ly/kDocB



_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

amir.herzberg
In reply to this post by Gervase Markham
On Nov 27, 7:42 pm, Adam Barth <[hidden email]> wrote:

> It's important to separate two concerns:
>
> 1) Malicious extensions
> 2) Honest extensions that have vulnerabilities (benign-but-buggy)

Absolutely. And I also completely agree with the rest of Adam's post
(below). Just let me add my 2cents - two more advantages to introduce
a `real` protection mechanism for extensions:

1. It would allow Mozilla and the community to inspect more carefully
sensitive extensions (these requiring strong capabilities), for
vulnerabilities (and intentional abuse / trapdoors).
2. It would allow users or user agents to decide whether to install a
specific extension based on its `capabilities profile`. Yes, naive
users may not be able to do this, but sysadmins may define defaults
for an organization, and anti-virus programs etc. can set up such
values.

So, I think this is a good idea. It may require significant work to do
this well, though... but this can be fun!

Best, Amir Herzberg

>
> I agree that the malicious extension problem is somewhat intractable
> because of the above concerns.  However, than news article is
> complaining about vulnerabilities in honest extensions.
>
> In the current extension system, any vulnerability in an extension is
> disaster because every extension runs with the user's full authority.
> That means if I XSS an extension, I can run arbitrary code on your
> machine.  In the DefCon talk, the presenters make this clear by
> installing VNC and remotely moving the user's mouse.
>
> A fortunate fact of the world is that the vast majority of Firefox
> extensions do not require the user's full authority.  (That is the
> statement I have a bunch of data to back up.)  If the extension
> ecosystem let authors restrict the privileges of their extensions (and
> encouraged them to do so), then vulnerabilities in extensions would be
> less severe because the attacker would obtain less that the user's
> full authority by compromising an extension.
>
> > The only solution to this problem, IMO, is to authenticate authors, not
> > code. If you know who the author is, to a sufficient level that there's some
> > chance of a policeman feeling his collar if he turns out to have written
> > code which steals all your passwords, then there's an incentive for good
> > behaviour. (This is how EV SSL certs work.) Of course, this works against
> > "anyone can author an add-on and put it on the web and have people use
> > it"...
>
> For the benign-but-buggy threat, the authors are perfectly nice
> people.  No amount of authenticating them is going to reduce the
> severity of vulnerabilities in their extensions.
>
> Adam

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Michael Lefevre-2
In reply to this post by ianG-2
On 29/11/2009 07:40, Kálmán „KAMI” Szalai wrote:
> Do we have friendly extension, or signed extension? Could you describe
> the validation process. Is it a go not go test or a detailed code
> review? Are there possibility that author create a good extension and
> change it for the 4th release to bad extension? Will we have a
> bugtracker to follow the possible (security) bugs in the extensions. Can
> we introduce "it is safe" tag for the really tested extensions?

I'm not part of the add-ons team, but I can try and answer anyway.
Firefox, by default, will only install extensions from
https://addons.mozilla.org - users can install addons from anywhere, but
they have to go through a security warning and a few mouse clicks before
Firefox will install addons from other sites.

The addons on the official site are reviewed, according to the process
at https://addons.mozilla.org/en-US/developers/docs/policies/reviews

>>> Installing an extension is like installing an application on your
>>> machine - it's just as trusted as any other application.
>>
>> Right.  Having said that, how does one give the users the tools to
>> figure that out?  Or is it the users' responsibility to figure it out
>> by themselves?
>>
> Yes, for example the extension can steal the keystrokes? Should I
> netbanking only in safe mode of Firefox?

As said above, extensions/addons are like installing an application.
Extensions can steal keystrokes, but also get passwords from your
computer, read your files, re-format you hard disk, or anything else.
Addons have the same privileges on your computer as Firefox itself, so
users need to have the same level of trust of addons as they do in
Firefox, or other applications they install on their computer.

Michael
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Adam Barth-8
In reply to this post by KAMI911 KAMI911
On Sat, Nov 28, 2009 at 11:51 PM, Kálmán „KAMI” Szalai
<[hidden email]> wrote:

> Adam Barth írta:
>> It's important to separate two concerns:
>>
>> 1) Malicious extensions
>> 2) Honest extensions that have vulnerabilities (benign-but-buggy)
>>
>> I agree that the malicious extension problem is somewhat intractable
>> because of the above concerns.  However, than news article is
>> complaining about vulnerabilities in honest extensions.
>
> And How can we avoid the Malicious extensions problems'.

I'm not sure.  That's a hard problem, but we can still make progress
on the benign-but-buggy case.

Adam
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Chris Hofmann-3
In reply to this post by Michael Lefevre-2

There is some early thinking about the Jetpack security model at

https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Jetpack_Security_Model

There is still alot of work left to do in driving out details around how
the capabilities will be checked by knowledgable reviewers, and surfaced
to users that might not be as good at  making the correlations between
capabilities in Jetpacks and possible risks.

Aza also put together a draft of an  introductory video to explain at a
high level how this system might work.

http://vimeo.com/7660200

definitely interested in feedback as the security model gets flushed out
and applied.

-chofmann

Michael Lefevre wrote:

> On 29/11/2009 07:40, Kálmán „KAMI” Szalai wrote:
>> Do we have friendly extension, or signed extension? Could you describe
>> the validation process. Is it a go not go test or a detailed code
>> review? Are there possibility that author create a good extension and
>> change it for the 4th release to bad extension? Will we have a
>> bugtracker to follow the possible (security) bugs in the extensions. Can
>> we introduce "it is safe" tag for the really tested extensions?
>
> I'm not part of the add-ons team, but I can try and answer anyway.
> Firefox, by default, will only install extensions from
> https://addons.mozilla.org - users can install addons from anywhere,
> but they have to go through a security warning and a few mouse clicks
> before Firefox will install addons from other sites.
>
> The addons on the official site are reviewed, according to the process
> at https://addons.mozilla.org/en-US/developers/docs/policies/reviews
>
>>>> Installing an extension is like installing an application on your
>>>> machine - it's just as trusted as any other application.
>>>
>>> Right.  Having said that, how does one give the users the tools to
>>> figure that out?  Or is it the users' responsibility to figure it out
>>> by themselves?
>>>
>> Yes, for example the extension can steal the keystrokes? Should I
>> netbanking only in safe mode of Firefox?
>
> As said above, extensions/addons are like installing an application.
> Extensions can steal keystrokes, but also get passwords from your
> computer, read your files, re-format you hard disk, or anything else.
> Addons have the same privileges on your computer as Firefox itself, so
> users need to have the same level of trust of addons as they do in
> Firefox, or other applications they install on their computer.
>
> Michael
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Adam Barth-8
On Sun, Nov 29, 2009 at 10:19 AM, chris hofmann <[hidden email]> wrote:
> There is some early thinking about the Jetpack security model at
>
> https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Jetpack_Security_Model

This looks like a great start.  A few things you might consider:

1) If the Jetpack is not signed with a CA-verified certificate, you
might consider having the developer self-sign the Jetpack.  That could
help with the issues raised in
<https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Code_Updating> for
unsigned Jetpacks.  (You can check that the update is self-signed with
the same key.)

2) The document doesn't explain how Jetpacks interact with web content
(e.g., web pages).  Many of the vulnerabilities in existing extensions
are due to unsafe interaction with malicious web pages.  You might
consider if there is a way to structure the API for interacting with
web pages to make that easier to do securely.  For example, you could
isolate the the content-touching parts of the Jetpack behind a JSON
message passing interface, like you've done with third-party
libraries.

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.

Adam
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Devdatta Akhawe
> 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) ?


thanks
devdatta
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Adam Barth-8
On Sun, Nov 29, 2009 at 6:34 PM, Devdatta <[hidden email]> 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) ?

That's a good question for Adrienne, but my understanding is the prefs
system can only store simple types like integers and booleans.  Now
that JSON.stringify and JSON.parse are implemented in Firefox,
localStorage can store many interesting objects.  I think the HTML5
spec also as support for storing things like images in localStorage,
but I'm not sure that's implemented in Firefox yet.

It's possible that we could design a persistent storage API that's
better optimized for extensions, but I think it makes sense to re-use
interfaces the web platform whenever possible.  For example, if jQuery
adds an abstraction for localStorage, Jetpacks can use that for free.

Adam
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Devdatta Akhawe
> system can only store simple types like integers and booleans.  Now
> that JSON.stringify and JSON.parse are implemented in Firefox,

The preference system supports Strings + Integers + Booleans. As of
now, afaik, localStorage is a key value system only supporting
strings.


Regards
Devdatta

2009/11/29 Adam Barth <[hidden email]>:

> On Sun, Nov 29, 2009 at 6:34 PM, Devdatta <[hidden email]> 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) ?
>
> That's a good question for Adrienne, but my understanding is the prefs
> system can only store simple types like integers and booleans.  Now
> that JSON.stringify and JSON.parse are implemented in Firefox,
> localStorage can store many interesting objects.  I think the HTML5
> spec also as support for storing things like images in localStorage,
> but I'm not sure that's implemented in Firefox yet.
>
> It's possible that we could design a persistent storage API that's
> better optimized for extensions, but I think it makes sense to re-use
> interfaces the web platform whenever possible.  For example, if jQuery
> adds an abstraction for localStorage, Jetpacks can use that for free.
>
> Adam
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

ianG-2
In reply to this post by Adam Barth-8
On 29/11/2009 18:28, Adam Barth wrote:

> On Sat, Nov 28, 2009 at 11:51 PM, Kálmán „KAMI” Szalai
> <[hidden email]>  wrote:
>> Adam Barth írta:
>>> It's important to separate two concerns:
>>>
>>> 1) Malicious extensions
>>> 2) Honest extensions that have vulnerabilities (benign-but-buggy)
>>>
>>> I agree that the malicious extension problem is somewhat intractable
>>> because of the above concerns.  However, than news article is
>>> complaining about vulnerabilities in honest extensions.
>>
>> And How can we avoid the Malicious extensions problems'.
>
> I'm not sure.  That's a hard problem, but we can still make progress
> on the benign-but-buggy case.


there are two popular ways to deal with this:

    * beforehand - review
    * afterwards - punishment

The good thind thing about "beforehand - review" is that it is
understandable.  The bad thing is that it doesn't scale very well, and
when it comes to user code, there aren't that many people who want to go
trawling through looking for yet more bugs in someone else's code.  "I'd
rather write it myself."  Or, at the best, the work falls on some, the
benefits on others (e.g., see over on the policy group for their review
process, where the tiniest operators pay for the reviews of the largest
operators).

In contrast, the notion of "afterwards - punishment" is a lot less
understandable.  There appear to be two popular ways:  reputation and
the long reach of the law.  Reputation can be used to damn a developer.
  The law can either lock him up or charge him all his profits.

It is this part that is often wrapped up in the so-called identity or
trust business.  If you know the guy's name, so the concept goes, you
can be safe, because if something goes wrong, you pass his name to the
Feds or the Mounties (they always get their man).  Or, you damn him to
all time on the mailing lists.

But this is specious.  For a start, he might be outside the Feds
location, and we know how they never ever break the rules and cross the
borders.  Or he might be a she, and the Mounties are stumped.  Or it
might be a false name.  Or or or....

It does have one advantage:  You can collect these names far more
efficiently than you can review code.  And, the cost falls on the
developer not someone else.  So we could say that the system scales very
well, as long as it rarely needs to be called upon.



So what to do?  One thing that does look better than either path is a
mixture of both.  A small amount of identity and a small amount of
review.  That is, once you've got your small identity handle, and it
relates to a small amount of review, another vista opens up:  Alice
can't get her code reviewed, it's not even allowed in the Queue ...
until she's reviewed Bob's code.  Or some metric.

Beyond spreading the load of the review, it also gives the review teeth.
  If the reviewee's code turns out to be bad, the reviewer's reputation
could suffer.  Which also points the bone of fear at the reviewer's own
code.

This method is called the web of trust.  The word trust there is a
misnomer ... we all think of trust as good, so putting it in there is a
standard marketing trick to make us think this is good.  But no matter
that;  the WoT allows the work of several people to relate to the work
of other people.  In a way that is shared, cheap, scaleable, and
community.  Developers working for developers;  hey, isn't that what
it's about?



iang
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Adrienne Porter Felt
In reply to this post by Adam Barth-8
(Previous e-mail was bounced)

On Sun, Nov 29, 2009 at 8:05 PM, Adrienne Porter Felt <[hidden email]>wrote:

> A fortunate fact of the world is that the vast majority of Firefox
>>> extensions do not require the user's full authority.  (That is the
>>> statement I have a bunch of data to back up.)  If the extension
>>> ecosystem let authors restrict the privileges of their extensions (and
>>> encouraged them to do so), then vulnerabilities in extensions would be
>>> less severe because the attacker would obtain less that the user's
>>> full authority by compromising an extension.
>>>
>>
>> Furthermore, this would allow the community to better scrutinize the
>> security of the smaller number of extensions that would require higher
>> privileges.
>>
>
> I generally agree with this point of view.  I like the idea of combining
> community review and least privilege.  If a developer asks for a lot of
> privileges (i.e., host system access), then that extension has to go through
> a review -- which may slow down getting the app listed.  Fewer apps have to
> be reviewed, and more developers are willing to request a small amount of
> privileges.  Only a small number of apps really need host system access, so
> that would be great.
>
> The problem that we run into here, though, is that host system access isn't
> the only thing to worry about (although it's the biggest one).  Access to
> web pages can still be abused, and extensions that want web access should
> perhaps still merit review.  A lot of extensions want web access, so a lot
> of extensions would still need review.  I don't know what to do about that.
>  We don't have the ability to do partial DOM access at the moment so we
> can't do a "web site with no password or cookie access" type of privilege.
>
> One idea might be to force a delay.  Like -- if you ask for host
> privileges, your app won't even start the review process for a week.  If you
> ask for arbitrary web access, your app won't start the review process for
> another 4 days.  If you ask for web access to only five sites or less, your
> app starts the review process in 2 days.  Etc.  That might bug developers
> enough to want to use as few privileges as possible.
>
> Another point I'd like to bring up is that a least privilege system (where
> the developer clearly declares all privileges) does make it easier to
> review, even if you still have to do a lot of reviews.  The reviewer knows
> exactly what the worst case scenario is; you don't need to waste time
> looking for sneaky evil system calls if you know the extension can't make
> any system calls at all.
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Safety of extensions (DefCon presentation)

Adrienne Porter Felt
In reply to this post by Adam Barth-8
(Previously bounced from the list)

On Sun, Nov 29, 2009 at 7:51 PM, Adrienne Porter Felt <[hidden email]>wrote:

> > 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) ?
>>
>
> It's not that extensions "can't" use with the preferences system.  That was
> not what I meant to imply -- lazy wording on my part.  Rather, developers
> choose not to use prefs when their data is complex -- they write XML or
> JSON.  IMO this is because (1) writing XML out to a file is simpler/more
> familiar and (2) the name "prefs" does not make it sound like a place for
> general data storage.
>
> If nsIFile were taken away, I personally think either prefs or localStorage
> would be good and usable alternatives (although I would suggest a name
> change to prefs), keeping in mind Adam's points.
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
12