1338690 - "youtube adblock" malware using "features" application directory

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Robert Helmer [:rhelmer]]

I've been watching all reported system add-ons we're seeing in Telemetry:
https://sql.telemetry.mozilla.org/queries/2678#table

An unexpected ID has been rising: {95E84BD3-3604-4AAC-B2CA-D9AC3E55B64B}

From a quick search, I think this is a malware add-on which we should block.

I believe blocklisting works for system add-ons, but I don't think we've tested it.

Comment 1

[Robert Helmer [:rhelmer]]

Note that since this is the Firefox application directory, it's very likely that this add-on is not sneaking in through Firefox but is being dropped in by some other pre-exising malware infection.

This isn't particularly surprising given bug 1277920 (and it's trivial to find other ways like bug 1292444) but we should still do something about it in the meantime.

Fixing bug 1277920 would at least cause a bit of friction for malware authors and is worth doing IMHO.

Comment 2

[Robert Helmer [:rhelmer]]

Can we put {95E84BD3-3604-4AAC-B2CA-D9AC3E55B64B} in the staging blocklist?

We need to test to make sure it'll work for system add-ons in the built-in location - I think it should, we allow them to be appDisabled just not userDisabled.

Comment 3

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

For reference, I don't see ID {95E84BD3-3604-4AAC-B2CA-D9AC3E55B64B} anywhere on AMO, suggesting the file was never signed. I do see a reference to it on bug 1329015 comment #1. Shell, do you remember where that ID came from? Could be because it showed up in a list of system add-on IDs, but I want to check.

Comment 4

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

The block is staged now. Testing instructions can be found here: https://wiki.mozilla.org/Blocklisting/Admin#Testing (may need tweaking, this is a new system).

rhelmer, are you doing the testing?

Comment 5

[Kris Maglione [:kmag]]

(In reply to Jorge Villalobos [:jorgev] from comment #3)
> For reference, I don't see ID {95E84BD3-3604-4AAC-B2CA-D9AC3E55B64B}
> anywhere on AMO, suggesting the file was never signed.

System add-ons shipped with the browser (which is what this is masquerading as) don't need to be signed.

Comment 6

[Robert Helmer [:rhelmer]]

(In reply to Jorge Villalobos [:jorgev] from comment #4)
> The block is staged now. Testing instructions can be found here:
> https://wiki.mozilla.org/Blocklisting/Admin#Testing (may need tweaking, this
> is a new system).
> 
> rhelmer, are you doing the testing?

Sure. Once I confirm that it does work with built-in system add-ons I'll ask if QA wants to take a look too before it goes live, since we haven't blocked add-ons in this location before.

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to Jorge Villalobos [:jorgev] from comment #4)
> The block is staged now. Testing instructions can be found here:
> https://wiki.mozilla.org/Blocklisting/Admin#Testing (may need tweaking, this
> is a new system).
> 
> rhelmer, are you doing the testing?

Hm, these instructions don't work for me... the `services.blocklist.bucket` setting does not seem to change the URL used for the blocklist, and I don't see this ID inside that URL.

Comment 8

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

Natim, can you confirm what the right steps are to test blocks that are staged?

Comment 9

[Robert Helmer [:rhelmer]]

I am testing on Firefox 51.0.1 (release) FWIW.

Comment 10

[Robert Helmer [:rhelmer]]

While we're getting the blocklist testing process sorted out, I hosted the blocklist locally and can confirm that blocklisting appears to work fine for built-in system add-ons.

The system add-on stays installed (since it's in the app dir we can't remove it, only the installer or updater can do that) and is set to appDisabled state.

Comment 11

[Rémy Hubscher (:natim)]

According to https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#2236
You need to set the extensions.blocklist.url prefs to:

https://firefox.settings.services.mozilla.com/v1/preview/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/

Comment 12

[Robert Helmer [:rhelmer]]

(In reply to Rémy Hubscher (:natim) from comment #11)
> According to
> https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.
> js#2236
> You need to set the extensions.blocklist.url prefs to:
> 
> https://firefox.settings.services.mozilla.com/v1/preview/3/%APP_ID%/
> %APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/
> %OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/
> %TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/

Thanks - I just tried this and the response is:

{"info":"https:\/\/github.com\/Kinto\/kinto\/issues\/","errno":999,"message":"A programmatic error occured, developers have been informed.","code":500,"error":"Internal Server Error"}

I am testing on Mac and the expanded URL is:

https://firefox.settings.services.mozilla.com/v1/preview/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/51.0.1/Firefox/20170125094131/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2015.6.0/default/default/1/1/new/

Comment 13

[Rémy Hubscher (:natim)]

We found a bug and we need Bug 1341012 to be fixed before approving the request.

Comment 14

[Rémy Hubscher (:natim)]

Robert, Mat put together an extention to help you switch between envs: https://github.com/leplatrem/aboutremotesettings

We are on our way to deploy the fix to stage I will let you know as soon as it is ready.

Comment 15

[Rémy Hubscher (:natim)]

Robert feel free to try the change by switching to the preview blocklist using leplatrem's aboutremotesettings add-on.

Comment 16

[Robert Helmer [:rhelmer]]

(In reply to Rémy Hubscher (:natim) from comment #15)
> Robert feel free to try the change by switching to the preview blocklist
> using leplatrem's aboutremotesettings add-on.

Thanks, I tried this but the manifest requires 53.* - I tried changing this but about:remotesettings doesn't seem to work on release (51.0.1)

Updating the setting directly per comment 11 does seem to work though.

I'd like to fix up https://wiki.mozilla.org/Blocklisting/Admin#Testing and I will contact you outside of this bug so we can figure out what the right way to test this should be going forward. Thanks for your help!

Comment 17

[Robert Helmer [:rhelmer]]

The blocklist seems to work for me on Firefox 51.0.1 on macOS, modifying the URL per comment 11.

Note that I don't have a sample of the actual malware, I am just using a stub add-on with the same ID.

Comment 18

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

Is there anything left to do before pushing this block live?

Comment 19

[Robert Helmer [:rhelmer]]

(In reply to Jorge Villalobos [:jorgev] from comment #18)
> Is there anything left to do before pushing this block live?

I'd like to test on Windows at least, will do so right now.

Comment 20

[Robert Helmer [:rhelmer]]

OK I've tested this on Windows and Mac, the bad ID is blocklisted as expected and other system add-ons are unaffected.

Comment 21

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

Andreas, please approve the pending block: https://settings-writer.prod.mozaws.net/v1/admin/#/buckets/staging/collections/addons/records?_k=ltio62

Already confirmed to work on comment #20.

Comment 22

[Andreas Wagner [:TheOne] [use NI]]

Approved.