1200144 - Add-on can disable update check (making Firefox report being "up to date" although update is available)

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Daniel Kabs, reporting bugs since 2002]

Attachment: Screen Shot 2015-08-30 at 13.13.39.png

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

Steps to reproduce:

The user can manually trigger Firefox to check for available updates. On a Mac this is done by clicking Firefox -> About Firefox. Then a window opens that shows the version number. If the installed version of Firefox is current, a text is displayed "Firefox is up to date". If a newer version of Firefox is available, the user is offered to start an update.

I'm running 40.0.2. Today I checked 
https://www.mozilla.org/en-US/firefox/40.0.3/releasenotes/ 
and learned that a new version of Firefox is available since 8/27/2015. 

To manually start the update, I opened "About Firefox"


Actual results:

- A window opens stating that "Firefox is up to date".
- Firefox does not detect update available at, e.g., 40.0.3
- see screenshot


Expected results:

- A window opens stating that a new version is available
- The user is guided through the update process.

Comment 1

[Loic]

Did the user try to update his version from a new profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

It's a probably a profile issue.

Comment 2

[Daniel Kabs, reporting bugs since 2002]

Loic, that is correct. Thanks a lot! When starting Firefox using a new and clean profile, the "about" window offers the update. This way Firefox was updated to 40.0.3


How can I find out what's wrong with the profile that's not showing the update?

Comment 3

[Loic]

The user can try to delete the "update" files from his local settings.

On Windows, these files are stored in the folder:
C:\Users\<username>\AppData\Local\Mozilla\updates\
Then each update is stored in a folder with alphanumeric string. So by deleting these folders, it should reset the update process/state and remove the update issues.

Comment 4

[Daniel Kabs, reporting bugs since 2002]

Hi Loic,
this issue was reported for Mac OS X. On a Mac, the profile folders are in 
/Users/<username>/Library/Application Support/Firefox/Profiles/
However, I found no "updates" folder in any of the profile folders. Therefore I assume the "updates" folder you refer to is outside of the profile folders. 

I found an update folder here:
/Users/<username>/Library/Caches/Mozilla/updates/Applications/Firefox/updates

I will report back after the next Firefox update is available and I can try your suggestion.

Comment 5

[Loic]

Yes, this folder with the "update" files (as .xml) are outside the profile. I don't know exactly the path on OSX but it's probably the one you linked (equivalent to local settings for applications on Windows).

Comment 6

[Daniel Kabs, reporting bugs since 2002]

@Loic: now that Firefox 41 is released, I followed your suggestion and deleted all files in the "updates" folder and - after that did not help - even the "updates" folder itself and "active-update.xml" + "updates.xml" (which are on the same directory level as "updates" folder).

In vain. Still "Firefox > About Firefox" mistakenly reports that 40.0.3 is up to date.

Therefore the issue is clearly associated with my specific profile.

Any other ideas why this is?

Comment 7

[Loic]

There is the reset feature: https://support.mozilla.org/en-US/kb/reset-firefox-to-fix-most-problems

Comment 8

[Daniel Kabs, reporting bugs since 2002]

Thanks. Will try the "reset" as a last resort.

Just figured that with my current (defective?) profile I can not access the update server https://aus4.mozilla.org manually. If I switch to a new profile, I can access this page (and the update works, too). So these two issues might be connected.

What could prevent Firefox to access "https://aus4.mozilla.org/" when I enter it in the URL bar? It seems that not even a HTTP request is generated for this URL.

Comment 9

[Loic]

Maybe bad prefs in the profile. Did you check the updates are allowed in the advanced settings?
Anyway, if the issue is fixed with a fresh profile, the fast way to fix it is resetting the profile to keep only the private data.

Comment 10

[Daniel Kabs, reporting bugs since 2002]

Loic, of course you are right. I should not investigate further into this issue and rather "reset" my profile. 

I'm puzzled that I fail to identify the root cause of the problem using well known methods. For example, I disabled all add-ons and plugins, still the issue exists, i.e. if I click on any of the links in comment #8, nothing happens (really nothing, not even a http request is issued, the Bugzilla page remains displayed). However, running Firefox in -safe-mode, the links work as expected. I wonder what -safe-mode does over manually disabling addons and plugins.

Comment 11

[Daniel Kabs, reporting bugs since 2002]

I found the culprit that prevented Firefox from accessing its update server aus4.mozilla.org.

It's an add-on (aka extension) which calls itself "web shield" with the identification {458fb825-2370-4973-bf66-9d7142141847}

Interestingly it hides itself from appearing on the add-on list by applying a special CSS rule. The CSS rule sets the "display" property of the add-on's list entry to "none". See screenshot. Therefore, I was unable to disable the add-on and I did not see Firefox' warning message about this unverified add-on.

I find this intriguing but also very alarming that

a) An add-on can  Firefox' update mechanism, and
b) An add-on can hide itself from the list of add-ons (rendering Firefox add-on related controls and warning means inoperable)

Comment 12

[Daniel Kabs, reporting bugs since 2002]

Attachment: Screen Shot 2015-09-29 at 09.53.58.png

Extension List (Tools > Add-ons) opened in Inspector while "web shield" add-on is installed.

Comment 13

[Daniel Kabs, reporting bugs since 2002]

FYI, I filed a separate bug #1209452 about the issue of CSS injection in order to vanish from Add-ons Manager's list of extensions.

Comment 14

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

A quick google search ["web shield" firefox add-on] shows that web shield is classified as adware or adware-related/PUP. Top result: https://www.pcrisk.com/removal-guides/8909-web-shield-adware

jorgev: I assume this would be easily noticed and rejected if the extension was ever uploaded to AMO for signing, but this seems serious bad behavior so NI'ing you anyway in case there's anything else to be done (add to blocklist maybe?).

Comment 15

[Daniel Kabs, reporting bugs since 2002]

Luis, I don't know how this extension got installed in my Firefox profile. *blush* I guess I'll never find out.

Of course I would have detected and removed this extension earlier if it had not hid itself from Add-ons Manager (bug #1209452).

Comment 16

[Daniel Kabs, reporting bugs since 2002]

I don't know if this is relevant but I analyzed how the add-on intercepts HTTP requests. It uses the API documented here:

>  https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/Intercepting_Page_Loads#HTTP_Observers

The extension adds an HTTP observer function httpRequestObserver

>  Services.obs.addObserver(httpRequestObserver, "http-on-modify-request", false);

The httpRequestObserver retrieves the requested URL and matches it against the following regex:

> /(\/\/aus.\.mozilla\.org\/|\/\/blocklist\.addons\.mozilla\.org\/|\/\/addons\.cdn\.mozilla\.net\/user-media\/addons\/.*hotfix)/i

If it matches, it calls cancel() on the respective nsIHttpChannel

>  httpChannel.cancel(Components.results.NS_BINDING_ABORTED);

Comment 17

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

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #15)
> Luis, I don't know how this extension got installed in my Firefox profile.
> *blush* I guess I'll never find out.

That's the thing with these extensions, they're sneaky. :) It was probably bundled with another application. But when there's one there are usually more, so I would recommend that you scan your system. It seems like it's a fairly known package so I suppose any adware/malware removal process of your choice will recognize it and deal with it successfully.

But before you do, perhaps you should temporarily save the extension xpi package file in a folder somewhere (I'm guessing you already did since you're looking at its code), in case it is needed as a reference point for this bug.

Comment 18

[Daniel Kabs, reporting bugs since 2002]

Attachment: example extension xpi package file

Comment 19

[Loic]

Could you make a run of Adwcleaner on your machine, theis "Web Shield" should be logged by this tool:
https://toolslib.net/downloads/viewdownload/1-adwcleaner/

Comment 20

[Loic]

NVM, you're on OSX.

Comment 21

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

Filed bug 1209588 to block the extension. Thank you for bringing this up.

Comment 22

[Robert Strong (they/them - no direct email)]

We no longer support these types of add-ons so resolving wontfix