Closed Bug 407315 Opened 17 years ago Closed 14 years ago

Extension Manager allows installing hidden extensions using a non-standard em:type

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.3a5

People

(Reporter: jwkbugzilla, Assigned: mossop)

References

Details

(Whiteboard: [AddonsRewrite])

You can put a line like the following in the install manifest of an extension:

        <em:type>1234</em:type>

This is a useful feature, e.g. in TomTom HOME we define a bunch of our own extension types. However, after you install such an extension in Firefox you will no longer be able to uninstall it - it will not appear in any of the lists the Extension Manager gives you. That means, once a malevolent extension is in your system, you can no longer get rid of it (unless you know which subdirectory to delete which most users don't).

I am aware the using install.js you can get the same effect - but my understanding is that this feature is going to be removed anywat.
This does seem undesirable, particularly since it can happen accidentally because of a typo in the manifest. It's worth noting though that once you install a malicious extension, it can just overlay the add-on manager to hide itself anyhow, so the attack vector here doesn't get them anything they didn't already have.  Still, as I say, this approach is both easier for attackers, and easier to accidentally get wrong for legitimate addons.

On the off chance that I am fundamentally misunderstanding something here, I'll leave it sec-sensitive for the time being, but imo this bug needs fixing as a potential user annoyance more so than as a security threat.
Copying mossop to confirm my addons-manager expectations, and madhava in case he has design ideas around what to do with addons-with-broken-categories.
We can easily block installing add-ons that have an invalid type, course that would cause problems for Wladimir. The reality is that there are better documentated ways to hide your extension once it is installed that we can't do anything about.
Dave - I think you're saying a) we can unhide this, b) fixing the accidental case by blocking install is easy, though it does nothing in particular to improve security here.

If so, let's unhide it, and morph the bug, because we might as well at least track the problem of accidental installs (especially as people like Wladimir start using alternate type-numbers for addons that a firefox user should not be installing anyhow)?
Well I didn't mention unhiding it, but it is certainly possible to lump all unknown types into the Extensions pane say. However I imagine that causes problems for Wladimir too.
(In reply to comment #1)
> It's worth noting though that once you
> install a malicious extension, it can just overlay the add-on manager to hide
> itself anyhow, so the attack vector here doesn't get them anything they didn't
> already have. 

You are right, however without using an unknown type the extension will still become visible if the user starts the browser in safe mode.

(In reply to comment #5)
> Well I didn't mention unhiding it, but it is certainly possible to lump all
> unknown types into the Extensions pane say. However I imagine that causes
> problems for Wladimir too.

Not really a problem for XULRunner-based applications (I am replacing extension manager UI anyway and I guess anybody introducing his own types will do the same). I am not sure what somebody would use custom extension types for in Firefox however.
(In reply to comment #6)
> (In reply to comment #5)
> > Well I didn't mention unhiding it, but it is certainly possible to lump all
> > unknown types into the Extensions pane say. However I imagine that causes
> > problems for Wladimir too.
> 
> Not really a problem for XULRunner-based applications (I am replacing extension
> manager UI anyway and I guess anybody introducing his own types will do the
> same). I am not sure what somebody would use custom extension types for in
> Firefox however.

Sure, except that the easiest way to fix this is at the component level, just change the type of any unknown typed-extensions into a known type. This would though make it basically impossible to use new types of add-ons without you changing the extension manager component itself.
Flags: blocking-firefox3?
not a blocker, would take a patch though.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
If you install a malicious extension, you've already lost in so many ways.  This is a bug but not a security hole.
Group: security
So actually this is really a non-issue. I should have looked deeper into this, if an add-on is of an unknown type it doesn't actually get loaded like other add-ons. So while you can't see the installed add-on to uninstall it, it also cannot affect Firefox like a normal add-on could.
When bug 406184 is fixed this will become more of a concern as unknown typed addons will be active and able to do things to the UI so we might want to fix this.

I have a rough plan of how to do it but it involves rewriting much of the template builder in the extensions UI so it produces templates using the new features in 1.9. I can probably do this but the question is whether Rob will have the time to review and if we even want to take such a change at this late stage?
not for a non-blocker, but keep it in mind for v.next
Product: Firefox → Toolkit
Blocks: 495687
No longer blocks: 495687
I'm not sure if this is the same bug or not, but the results are the same so I'll add it here.  Simply adding the following line to the install.rdf file will make an add-on hidden.  It won't show up in the add-on manager.

<em:hidden>true</em:hidden>

Sun does this with their Java Console extension that gets installed with every version of Java (at least on Windows).  Each version of Java uses a different GUID for the included extension and old ones aren't removed.  As such most people probably have upwards of 10 different Java Console extensions installed and never even know it because they are all hidden.
(In reply to comment #14)
> I'm not sure if this is the same bug or not, but the results are the same so
> I'll add it here.  Simply adding the following line to the install.rdf file
> will make an add-on hidden.  It won't show up in the add-on manager.
> 
> <em:hidden>true</em:hidden>

It is not the same issue. And that would only work for extensions installed in restricted install locations, so those installed by the user in the profile cannot hide themselves in this way. We also removed support for this in bug 508109
Summary: Extension Manager allows installing hidden extensions → Extension Manager allows installing hidden extensions using a non-standard em:type
Fixed with the new extension manager
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Dave, with the new add-ons manager we do not install those extensions anymore, but we also don't show up any message in the error console which can help to identify why we don't do that. It's similar to what i have mentioned on bug 292854 for an invalid install.rdf file. Shall we cover all those instances in their own bugs or is a combined bug preferred?
Assignee: nobody → dtownsend
Status: RESOLVED → VERIFIED
Depends on: 553169
Flags: in-testsuite?
Flags: in-litmus-
Whiteboard: [AddonsRewrite]
Target Milestone: --- → mozilla1.9.3a5
(In reply to comment #17)
> Dave, with the new add-ons manager we do not install those extensions anymore,
> but we also don't show up any message in the error console which can help to
> identify why we don't do that. It's similar to what i have mentioned on bug
> 292854 for an invalid install.rdf file. Shall we cover all those instances in
> their own bugs or is a combined bug preferred?

File a bug for that, we certainly should be.
You need to log in before you can comment on or make changes to this bug.