1209452 - Extension can hide itself from Add-ons Manager Extensions tab (about:addons)

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Daniel Kabs, reporting bugs since 2002]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150917150946

Steps to reproduce:

I observed a (potentially malicious) extension that inject special code which modifies Add-ons Manager in order to hide itself from the list of extensions. 

The extension uses Stylesheet Service

  https://developer.mozilla.org/en/docs/Using_the_Stylesheet_Service

to dynamically load a style sheet 

  sss.loadAndRegisterSheet(uri, sss.USER_SHEET)

containing the following CSS

  @-moz-document regexp(".*about:addons.*")\
    {\
      .addon[value="EXTENSION_ID"]{\
            display:none;\
      }\
    }

where EXTENSION_ID has been replaced by the GUID of the extension and the CSS has been represented as a "data:text/css;base64" URI.  


I believe that an extension must not be able to hide itself from the user by way of being able to remove itself from the list of extensions. I don't know if this is "allowed by design" or not. If this is "allowed by design", you can close this bug.

- Extension with the above code has been installed.
- Open Tools > Add-ons OR enter "about:addons" in URL bar
- A page opens with a list of extensions ("Extensions" tab of Add-ons Manager)


Actual results:

Not all installed extensions are listed. At least all enabled extensions should be listed here.


Expected results:

All installed extensions are listed.

Comment 1

[Daniel Kabs, reporting bugs since 2002]

For the sake of completeness, I came across this issue when researching a problem with an extension that prevents Firefox from updating (by intercepting connections to mozilla.org's update server), see bug #1200144

Comment 2

[Luís Miguel [:quicksaver] (not reading bugmail)]

It's highly unlikely this can simply be prevented within Firefox itself, there are tons of ways to hide or disguise an extension in the list.

Instead, you should provide the name and id of the extension, so that the AMO team can properly handle it if you think it is bad behavior on the extension part; i.e. if it's not approved and signed or even blacklisted, it won't be installed at all in Firefox.

Comment 3

[Daniel Kabs, reporting bugs since 2002]

Attachment: Screen shot showing resulting extension list (Tools > Add-ons) opened in Inspector while "web shield" add-on is installed.

Comment 4

[Daniel Kabs, reporting bugs since 2002]

I don't like the idea that extensions govern which extensions Add-ons Manager displays.

I think the user should be in control over extensions. The "control" means should not be commandline based (e.g. remove the xpi from the extensions folder) but rather GUI based, exactly what Add-ons Manager is made for. To be able to exercise this control, Add-ons Manager needs to be robust and immune to manipulations from extensions. Thanks.

Comment 5

[Jorge Villalobos [:jorgev] (he/him)]

The current add-on model doesn't allow that level of control. However, this is changing in the future: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

There's nothing we can do about this until we deprecate the old add-on model. In the interim, we're deploying mandatory signing, which should help mitigate bad code like this.

Comment 6

[Gingerbread Man]

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #0)
> I believe that an extension must not be able to hide itself from the user by
> way of being able to remove itself from the list of extensions. I don't know
> if this is "allowed by design" or not.

“Prevent the add-on from appearing in the Add-on Manager” is specifically prohibited by the add-on policy:
https://developer.mozilla.org/en-US/Add-ons/AMO/Policy/Extensions

(In reply to Luís Miguel [:quicksaver] from comment #2)
> Instead, you should provide the name and id of the extension

{458fb825-2370-4973-bf66-9d7142141847}
the file is attachment 8667315 [details] — posted at bug 1200144, comment 18.

(In reply to Jorge Villalobos [:jorgev] from comment #5)
> There's nothing we can do about this until we deprecate the old add-on
> model. In the interim, we're deploying mandatory signing, which should help
> mitigate bad code like this.

This thing should be blocklisted instead of waiting for add-on signing to go into effect.

Comment 7

[Gingerbread Man]

(In reply to Gingerbread Man from comment #6)
> This thing should be blocklisted instead of waiting for add-on signing to go
> into effect.

I just noticed bug 1209588 has been filed for that, so that's a relief.

Comment 9

[Sergey Rozhenko]

(In reply to Jorge Villalobos [:jorgev] from comment #5)
> The current add-on model doesn't allow that level of control. However, this
> is changing in the future:
> https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-
> add-ons/
> 
> There's nothing we can do about this until we deprecate the old add-on
> model. In the interim, we're deploying mandatory signing, which should help
> mitigate bad code like this.

O_O

Let me correct you. Mandatory signing would be completely irrelevant to this kind of malware. See https://bugzilla.mozilla.org/show_bug.cgi?id=1231582 for an example.

As for WebExtensions API, it sounds like extensions wouldn't be able to modify browser XUL and functions inside browser's JS code? What is that supposed to help with? I mean something serious. I don't even consider the issue malicious extensions here, because is importance is fully negligible in comparison. If that change is the case, it would effectively kill FireFox, making it nothing more than a slower Chrome. Ability to change every aspect of interface is the essence of FireFox.

Comment 10

[Tony Mechelynck [:tonymec]]

(In reply to Sergey Rozhenko from comment #9)
> 
> O_O
> 
> Let me correct you. Mandatory signing would be completely irrelevant to this
> kind of malware. See https://bugzilla.mozilla.org/show_bug.cgi?id=1231582
> for an example.

The mandatory add-on signing which is mentioned here is mandatory add-on signing _by Mozilla_ and is accompanied by a preliminary code review. Anyone can ask it for any add-on but it may increase the AMO reviewers' workload, and that, I suppose, is one of the reasons they want to kill it ASAP by dropping XPI (XUL+(possibly)XHTML+JS+CSS) extensions down the nowhere hole. But it ought to stop the grossest kinds of abuse. Maybe it won't stop "display: none" styles, but that only makes the mischievous add-on hard to remove, it doesn't in and of itself, for instance, make your computer an open relay or an unwitting participant in a DDoS attack.

> 
> As for WebExtensions API, it sounds like extensions wouldn't be able to
> modify browser XUL and functions inside browser's JS code? What is that
> supposed to help with? I mean something serious. I don't even consider the
> issue malicious extensions here, because is importance is fully negligible
> in comparison. If that change is the case, it would effectively kill
> FireFox, making it nothing more than a slower Chrome. Ability to change
> every aspect of interface is the essence of FireFox.

All right, so where do you place the bar between what is acceptable and what isn't? "[T]o modify browser XUL and functions inside browser's JS code", if allowed with no restraint, means allowing at least some malware behaviour. OTOH, there are some changes which could be regarded as "less harmful" and still allowed. I'm thinking, for instance (but don't forget that I'm not a Firefox developer) of changing the size and/or the font of the menu and button text: this should be OK; indeed some people might prefer very big text because otherwise they cannot read it, while others would prefer very small chrome text in order to have the most possible real estate for content pages. Then what about adding buttons with some well-defined set of functionalities? They would have to be well-defined indeed: Restart the app, for instance, might be OK, if it is done in such a way that your preferences about getting an are-you-sure dialog, or not, when closing multiple tabs, are respected. Sending your whole browser history to https://evil.spammers.com/ is probably not. Nowadays unsigned add-ons, sent to you under a nice name and unchecked by AMO, could do both the good and, behind your back, the bad; and some undoubtedly already do it. Enforcing signing-and-review by AMO would probably stop the grossest of abuses but at the cost of increasing the permanent workload of AMO reviewers. The new, more restricted category of addons is (IIUC) only partly defined. Let's hope that the developers will find the golden middle between power and security. I hope they will, because if they don't it might be the end of Firefox indeed.

Comment 11

[Sergey Rozhenko]

(In reply to Tony Mechelynck [:tonymec] from comment #10)
> But it ought to stop the grossest kinds of abuse. Maybe it won't stop
> "display: none" styles, but that only makes the mischievous add-on hard to
> remove, it doesn't in and of itself, for instance, make your computer an
> open relay or an unwitting participant in a DDoS attack.

It does. A GreaseMonkey script (masked by said trick) can easily take part in a DDoS attack. Or steal passwords, etc.

> All right, so where do you place the bar between what is acceptable and what
> isn't? "[T]o modify browser XUL and functions inside browser's JS code", if
> allowed with no restraint, means allowing at least some malware behaviour.

I draw the line right there, allowing ANY malware behavior, as it is now. Like I said above, even GM scripts can do enough harm, so any attempt at anti-XPI security won't help, extensions would be almost as dangerous potentially.
Mandatory extension signing is supposed to protect the user against an attack that's already happened. His computer has already been infected, and may be manipulated by the malware in any fashion. Yet, Mozilla wants to protect from infection getting into FireFox without the user noticing. Won't ever protect from, say, substituting FireFox executable (or shortcut, like some stupid malware does today), but is supposed to make things a little bit safer, somewhat. Signing itself is a good thing, it can warn the user if he downloads an extension unchecked by Mozilla. But mandatory signing hardly makes sense. Same applies to dropping XPI.

You've mentioned money spent on reviewing addons and I also think it's one of central issues here. What dropping XPI would do is simplify addon review process. It will also cut down the number of addons to review, as many of them won't be possible to implement in the new model...

Comment 12

[Tony Mechelynck [:tonymec]]

In answer to comment #11.
Hm, Allowing any malware behavior, that's pretty high. AFAIK there's no certain way to do that short of prohibiting any XPI extensions, and maybe also any support, or any but very limited support, for JS in pages browsed. You yourself say it doesn't make sense. So what? You can't have your cake and eat it too.

OTOH, I see many users hollering against the upcoming removal of XPI support, saying that what made Firefox great was its customizability, and that if Firefox becomes a Chrome copycat it will lose all the users it has. I suppose theres's no way to content everybody.