Closed Bug 1757349 Opened 3 years ago Closed 3 years ago

Firefox add-ons unload silently (eg NoScript, uBlock Origin)

Categories

(WebExtensions :: General, defect)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1355239

People

(Reporter: cheater00, Unassigned)

Details

(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Reproduction steps:

  1. have a very large Firefox profile with 100s of windows with 100s to 1000s of tabs in each
  2. install some add-ons
  3. run it for a while (days-weeks), while also running other memory hungry applications (computer games? productivity software?), and wait for the add-ons to crash. The add-ons are now inactive and they have no effect.

This eventually triggers either tabs crashing, or a silent failure in the add-ons due to the add-ons crashing. This latter situation is severe because many add-ons are crucial to security. For example, a website might be safe to visit with add-ons like NoScript, HTTPS Everywhere, uBlock Origin, or one of the Greasemonkey derivatives. When one of them fails, these websites might run malicious code that would otherwise be disabled. Ultimately this can lead to unexpected RCE, XSS, or clickjacking where it would not have happened had something like NoScipt been running. This problem is insidious because it is not a security vulnerability itself, it just makes security vulnerabilities easier to deliver to people who don't restart their browser. It can also lead to leakage of personal data - trackers that have been bypassed by eg NoScript or Decentraleyes are now active, and the user can be tracked.

As a fix, the add-ons should be silently reloaded, and navigation and network i/o should be stopped until that happens. If this proves impossible, a system pop-up should inform the user that a crash has occurred that cannot be recovered from, and the add-ons cannot be reloaded. The user should be given a chance to finish whatever work they're doing (eg copy out text of a post they've been writing), and then the browser should be restarted. Perhaps flagging add-ons as security add-ons would be smart, so that their loss of function immediately stops navigation and network i/o until functionality can be restored. There should be a continuous, deep liveness check on every addon, whether it's a security addon or not.

Flags: sec-bounty?

Note: personally I experience this bug every few weeks since maybe a few months ago. Disabling and re-enabling the add-ons reloads them, but I have to figure out that they crashed in the first place. Sometimes while doing that (disabling-and re-enabling), Firefox will crash.

It's not clear to me this is something that can be deliberately exploitable by a malicious actor, ie if they can cause the add-ons to be unloaded or w/e, and thus needs to be kept security-sensitive, but I guess I will defer that question to the add-ons team...

Component: Security → General
Product: Firefox → WebExtensions

I believe it can be triggered by a website loading a very large amount of stuff into memory. I know this bug triggers much more easily if I have several gmail tabs open at the same time, or Facebook, or Instagram. I haven't reported it immediately because I've been watching for this specific behavior and it seems to check out thus far.

A little bit more background - two probably separate behaviors, each of which might be related to this issue.

  1. A while back, Firefox used to have a bug where once it started using too much memory, it would create visual corruption. The whole window including the website would be made up of a mosaic of squares, and if you scrolled the website, the squares scrolled, but it was like it was just displaying the wrong squares. This behavior hasn't surfaced in a while, which I attribute to either nvidia fixing something in their drivers, or Microsoft changing something in Windows, or Firefox changing something about how memory is handled. If it's the last bit, then maybe those changes introduced the bug I'm describing in this ticket. The bug in this ticket only started surfacing after the mosaic corruption bug disappeared, but I don't know if it started happening immediately after that. I always keep my Firefox auto-updated, but I just don't remember the switchover moment.

  2. When memory usage gets very high, either this add-on crash happens, or tabs crash, or sometimes it's both. This leads me to believe that the javascript of the add-ons runs inside a similar object as the javascript of a tab, and that those crash or get OOMed in similar ways. When a tab crashes, a UI is displayed inside it asking you to reload it, which is perfectly good. Maybe someone just used that behavior for the add-ons, and thought "I'll add a UI for this later". However this is not good behavior since having those add-ons disabled even for one minute can lead to security issues that are mentioned above.

About my system:

Windows 10 64-bit, always at latest build, including optional updates.

Intel 8086K processor with 64 GB of ram, and Samsung 970 Pro 1TB SSD for the C: drive, GeForce 1080Ti graphics card with latest drivers.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

:robwu, thanks for marking a duplicate, this is a 5 year old report, and it clearly has severe security and privacy issues, please revise the type (bug, not enhancement) and severity and priority.

Although there is no visible activity (patches) on the linked bug, we are working on rearchitecting the extension framework to support unreliable processes in its design.

Flags: sec-bounty? → sec-bounty-
Group: firefox-core-security
You need to log in before you can comment on or make changes to this bug.