291565 - Extensions should be checked to see they are not stealing users' passwords.

Status: VERIFIED DUPLICATE of bug 245198

(addons.mozilla.org Graveyard :: Administration, defect)

Description

[Cameron]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: 

Extensions can read and write to the saved passwords file. (Tools -> options ->
privacy -> saved passwords.) The Gmail notifer extension does this. I've not got
the skills to do so, but couldn't an extension copy this data and send it back
to a remote server? This of course wouldn't be detected by many firewalls as
access has been granted to Firefox.

If so, then there are two solutions.
1) All extensions submitted to UMO should be tested to see if they're phoning home.

or
2) Extensions may only read from saved passwords which they create.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Dave Miller [:justdave]]

Fixing security group.

Comment 2

[Daniel Veditz [:dveditz]]

#1 is a non-starter, a truly malicious extension would find a way to evade
whatever limited testing we could afford to do (wait 6 months to get maximum
spread before doing any detectible evil?). Unless by "tested" you meant a code
audit, but I'm not sure how much of that we could do in practice. Any extension
that contains binary components would not be auditable.

#2 is not possible with the current architecture. When chrome script is running
we haven't kept track of where it has come from.

We should definitely make #2 part of UMO policy though, as well as limits on
what "phoning home" extensions can do. Or since some extensions must make server
contacts to do what they do (WeatherFox, Google pagerank) I'd settle for clear
disclosure to users of what network connections each extension initiates.

Comment 3

[Scott Kveton]

The ability of extensions to be able to read this information is, IMHO, an
inherent problem with Firefox.  The extension API should not allow that.  Trying
to push the burden of this work onto the UMO staff is just plain crazy because
a) we can't keep up with the number of extensions and b) no matter how hard we
try, somebody is bound to get _something_ through.

We can definitely make #2 a policy but it will be extremely difficult to enforce
until after the fact.

Many of the developers already have their apps phone home.  For example, some do
it for an image in the extensions panel.  This way they can gather statistics
about how many people are using the application, etc.  We can create a policy or
even limit the applications that do this but if they *can* do it within the
extension API, they *will* do it.  We can ask that the developers disclose this
information but again, its hard to enforce this until after the fact.

UMO is a beast but its going to be one of the most critical components of
Firefox that differentiates it from competing products.  IMHO we have to embrace
the community and trust them first and ask questions later (see "The Cathedral
and the Bazaar" -- UMO is no Cathedral).  We can put all the policy we want in
place, but we want to encourage development of extensions and more importantly
their listing on UMO.

Comment 4

[Daniel Veditz [:dveditz]]

By "policy" I mean clearly posted ethical guidelines for non-evil extensions.
Not everyone has the same understanding and posted guidelines will help keep the
well-intentioned extension authors within reasonable limits. Diclosure of the
borderline bits will warn away users who aren't comfortable with those actions
rather than have a controversy later when it's discovered.

> The ability of extensions to be able to read this information is, IMHO, an
> inherent problem with Firefox.  The extension API should not allow that.

Gecko knows the distinction between "chrome" and "content", that's all. The
"Extension API" is strictly a way to tell Gecko to load more chrome. There is no
way to sandbox this and we should not sugarcoat the fact that installing an
"extension" is INSTALLING SOFTWARE with all the risks that entails. Community
policing is OK as long as there's an easy-to-use mechanism for doing that (e.g.
ebay's feedback mechanism: # of feedbacks, % negative, ability to list just
negative ones to avoid being swamped by shills, etc. are all aids in trying to
gauge reliability and safety).

Comment 5

[Cameron]

http://www.mozilla.org/projects/security/security-bugs-policy.html
"However we will ask all individuals and organizations reporting security bugs through Bugzilla to follow the voluntary guidelines below:
...
Please try not to keep bugs in the security-sensitive category for an unreasonably long amount of time."

What do you folks want to do with this?

Comment 6

[Daniel Veditz [:dveditz]]

The update security group might have a separate policy for security bugs, but I suppose if it doesn't the client security bug policy is a good default.

This bug probably shouldn't have been private to start with, there is no exploit described here and I wouldn't think our policy discussion is private either since we'll have to get community buy-in on any such policy.

Comment 7

[Cameron]

-> Wontfix?

Comment 8

[Daniel Veditz [:dveditz]]

I wouldn't WONTFIX this, this is a perfectly reasonable expectation for an AMO-hosted (assumed trusted by users) extension. Could be duped to any "AMO extension review policy" bug we might have, I suppose.

As a practical matter we won't be able to review all extensions at this depth. This is one of the reasons we need a multi-tier AMO and should steer most normal users toward the "trusted/reviewed/polished" tier and completely hide the alpha-quality unreviewed extension tier from non-developers. I assume there'd be a middle "beta" quality tier that's not hidden, but not the first thing you see either. But I'm getting pretty offtopic for this bug.

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

*** This bug has been marked as a duplicate of 245198 ***