1001375 - Installed Addon not shown in about:addons

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Fred]

Attachment: gui-less.xpi

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

I've found an extension, that was installed on two different windows machines with the newest FF28 but was not shown in the about:addons tab. It gets only listed in the firefox healt report (detailed version). 


Actual results:

I suspect, that this addon is designed to be as stealthy as possible and serve as a foot-in-the-door for additional installations via the update.rdf.
On the systems where it was found, another addon was installed, which injected ads into google searches and other pages. Those addons where listed in about:addons. They were named "skype helper" and "HTML5 Extension free".


Expected results:

Every addon that is installed should be listed in the UI of about:addons. There should be no! way of hiding installed addons. I've attached the "stealth addon" in question and would like to know, why this is possible. I'm strongly suspecting a wide spread addon (~2mio users claimed) to have installed this ad-injecting extension mayhem during an update. As I have no proof, I do not want to disclose the name of the suspected culprit publicy.

Comment 1

[Benjamin Smedberg]

Can you please also copy the data about these extensions from your about:healthreport?

Comment 2

[Benjamin Smedberg]

Taking for investigation, we might well turn this into a blocklist bug.

Comment 3

[Fred]

Attachment: Malicious Code in Profile\Jetpack-Folder

This zip contains a folder within the user profile from one of the machines where the malicious plugin was found. Could not evaluate the eval( code yet.

Comment 4

[Fred]

Attachment: ad-injector extension which got presuably installed by gui-less extension

This extension was also found on the computer, where the gui-less addon was installed. It's modify date suggests a connection between those two addons. The name of the extension is "HTML5 Extension Free", how ever on another computer the same extension was named "Skype Helper".

Comment 5

[Fred]

Attachment: 2 outputs of about:healthreport

The attached health reports are taken:
1) directly after installing the malicious extension in a "new" firefox (portable, new profile).
2) after restarting the browser once.

As you can see, a second extension gets installed in between. This second extension is listed in about:addon, the first one is hidden. THERE IS NO USER INTERACTION REQUIRED FOR INSTALLATION AND NO VISUAL FEEDBACK DURING INSTALLATION!

After closing the browser a second time, the jetpack-folder gets populated with the attached json file.

Regarding your blocklist suggestion: I don't know what blocking possibilities there are for malicius addons, but note that the UUID of any extension and the name of the ad-injector seems to be randomly generated during installation!

Comment 6

[Fred]

Attachment: {7dc7890c-b0b3-40e2-8758-7f9965d01ac2}.xpi

I've found another computer at work with the problem. I've attached the extension which was installed there. It also does not show in "about:addons". After installing this extension, it immediatly downloads another extension without user interaction and goes into hiding. I really think, that those two things should not be possible!

Comment 7

[Fred]

Do you need any more information to deal with this bug report?

Comment 8

[Kris Maglione [:kmag]]

Please never upload potentially malicious XPIs with an application/x-xpinstall content type.

Comment 9

[Kris Maglione [:kmag]]

As far as I can tell, this is mostly a data logger add-on. It sends data such as the list of all URLs visited, all add-ons installed, ... to 'http://watcher.aws.sparpilot.com', and at one point accepts the URL of an add-on to install in return. It does seem that a lot of the code is disabled, though.

It does hide itself from about:addons, using some crude CSS.

Anyway, these are randomly generated IDs and names. The best key we can block on is the updateURL, which is 'https://dummf1up57pez.cloudfront.net/watcher/update.rdf'

Comment 10

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

I'll block it once we sort out a bug in metadata blocks. Should only be a couple of weeks.

Comment 11

[Fred]

Regarding Kris' comment, it seems to me that blocking one URL will not fix the underlying problem, that addons can hide themself with "crude CSS" from the user or that one addon can install more addons without user interaction. Wouldn't it be a better idea to look into these problems besides blocking a single instance of the problem?

Comment 12

[Daniel Veditz [:dveditz]]

There is not much Firefox can currently do to prevent an addon from doing this kind of thing. We can try to catch it at review time, but malicious add-ons like this obviously don't submit themselves for review.

What we are doing
* require add-ons to be signed by us, even if not served from AMO. This injects a review step, and makes it easier to block add-ons after the fact.
* develop a more robust Add-on API that does not give addons full power. That will make review easier and more reliable. We've recently announced starting work on a WebExtensions API, but that's a long range plan and it will take a while to get current add-ons weaned off the current way of doing things.

That work is on-going, and there is nothing about this bug to be done on the client (Product:Core) side. Either we blocklist these or we don't (can't, most likely), but that's on the AMO side.

Comment 13

[Daniel Veditz [:dveditz]]

The add-on folks don't want to block on this, does that mean we should just close it?

Dave: can you think of something beyond my thoughts in comment 12 that would make you think we might be able to solve this on the client?

Comment 14

[Dave Townsend [:mossop]]

(In reply to Daniel Veditz [:dveditz] from comment #13)
> The add-on folks don't want to block on this, does that mean we should just
> close it?
> 
> Dave: can you think of something beyond my thoughts in comment 12 that would
> make you think we might be able to solve this on the client?

Short of us re-implementing the add-ons UI as something native that XUL can't touch no I don't think there is anything further to be done here.

Comment 15

[Andy McKay]

We've got add-on signing coming, as pointed out in comment 12.

Comment 16

[Daniel Veditz [:dveditz]]

I guess we close this then? We already know malicious add-ons can do anything Firefox can do, including
 a) modify the about:addons UI to hide itself
 b) install add-ons (because Firefox can install add-ons)

We are trying to develop less powerful class of addons (web extensions) which will somewhat address these points, and in the meantime we're trying to root out malware by forcing them through our review and signing process. As a "Toolkit" bug there it nothing more to do here. If this specific add-on has a polymorphic ID then we can't even blocklist it on the AMO side.