Closed Bug 382708 Opened 13 years ago Closed 10 years ago

extension can specify arbitrary update URL, despite the absence of the updateURL property in install.rdf

Categories

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

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: neonile, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: 

There is a way for an extension to programmatically set a per-extension Firefox preference that allows it to specify an arbitrary URL to check for updates, without having to specify the updateURL property in install.rdf. This is documented here: http://kb.mozillazine.org/Manage_extension_updates_by_locale. 

Here is some sample code for doing this, assuming the extension ID is
"sample@site":
const updateURL = "http://www.site.com/update.rdf";
const prefs = Components.classes["@mozilla.org/preferences-service;1"]         
        .getService(Components.interfaces.nsIPrefBranch);
prefs.setCharPref("extensions.sample@site.update.url", updateURL);

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



The only easy way of fixing this is to completely disable this per-extension preference. Otherwise, program analysis of the extension code would arguably be necessary to determine whether it sets the preference at runtime.
Version: unspecified → 3.0
Assignee: nobody → fligtar
Status: UNCONFIRMED → NEW
Depends on: 371210
Ever confirmed: true
Hardware: PC → All
Version: 3.0 → unspecified
I think that fixing this will add very little value, if any value at all. Extensions can do everything they like, so if we block this method, extensions can just make their own update mechanisms or find other ways to tap into the update service. If we should increase the level automatic testing of extensions, I think it would make more sense to check for malware than this.
(In reply to comment #1)
> I think that fixing this will add very little value, if any value at all.
> Extensions can do everything they like, so if we block this method, extensions
> can just make their own update mechanisms or find other ways to tap into the
> update service. If we should increase the level automatic testing of
> extensions, I think it would make more sense to check for malware than this.

You are right that extensions can implement their own update mechanisms (e.g. Google Browser Sync does that), but doing so is much more difficult for mostly-hobbyist extension developers. I believe that this fix will remove the low-hanging fruit for those who attempt to circumvent the Firefox update framework, and that therefore there is value in it. 

For a more detailed discussion of the spectrum, see this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=378216
If you do not allow updateURL's in the install.rdf then you should not allow this method of changing the update url either. Equally you should not allow add-ons to circumvent the update process by using their own. There always was a policy statement explicitely saying that such behaviour was not allowed for add-ons that were hosted on AMO (though admittedly it's tough to detect the latter automatically). Unfortunately I can't find the policy statement any more so I don't know whether it really applies.
I plan on fixing this after we get the framework for looking through an extension for certain regex matches done. Unfortunately, that probably won't happen soon.

In the meantime, I zipgrepped through all of the public extension files for a few things, one of which being update.url. Sometime soon I'll be going through the results of that and filing bugs about the extensions that are using this method.
Assignee: fligtar → nobody
I've filed bug 395765 suggesting that we just drop this method of setting the update URL. Though I guess you'll still want to think about it for supporting Firefox 2 etc.
Summary: extension can specify arbitrary update URL, despite the absence of the updateURL propery in install.rdf → extension can specify arbitrary update URL, despite the absence of the updateURL property in install.rdf
Justin - what is the bug covering the framework?
I think we can resolve this bug - check out all_security_filterUnsafeSettings on line 546: http://viewvc.svn.mozilla.org/vc/addons/trunk/site/app/controllers/components/validation.php?view=markup
Seeing as there haven't been any comments, I'm marking this as resolved.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.