672630 - Stop using user.js as it's exploited by malware

Status: NEW

(Firefox :: General, defect)

Description

[[:Cww]]

user.js allows some third party programs to overwrite default Firefox behavior and make settings unchangeable or revert on restart. It's most commonly used by malware/installers to do one of the following:

Change the default home page/startup behavior
Change keyword.URL
Disable the popup blocker
Change the user agent
Enforce a proxy (and then all craziness can ensue)
Change search plugin order

I'm sure there are more but those are the ones that users complain about because they can't revert those changes without diving through their filesystem.

Let's just stop respecting user.js or give prefs.js priority. If a user makes a setting change, it shouldn't just disappear on the next run.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I suspect this won't really help much. Not reading other pref defaults will likely break many valid use cases, and the malicious (or well meaning but incompetent) addons/programs will just move to slightly more complicated but still easy solutions, like editing firefox.js directly.

Comment 2

[Justin Wood (:Callek)]

If the reasoning is purely because malware/etc. abuse it, then IMO we should wontfix this, if malware gets on your system to mod user.js anyway, they have the abil to entirely replace Firefox, run actual programs at sys startup etc.

Respecting user.js allows deployment type users to do things that they don't want to be easily disable able (addon) that they feel is needed in their environment

Comment 3

[Jesse Ruderman]

There are several legitimate reasons for users to use user.js instead of prefs.js:

* Sharing your most important prefs between profiles or computers.

* Preventing your prefs from being forgotten as you switch between build types, channels, or OSes that have different defaults.
** e.g. Ensuring browser.dom.window.dump.enabled stays true as you switch between opt builds (where it defaults to false) and debug builds (where it defaults to true).

* Making bulk changes to Firefox prefs while keeping the instructions open in Firefox (e.g. https://developer.mozilla.org/en/Midas/Security_preferences)

Maybe we can come up with better ways to support each of these use cases, though!

In general, I'm wary of removing Firefox features just because they are currently being abused by third-party software.  Abusive third-party software will always find a way to screw with Firefox.

Comment 4

[[:Cww]]

(In reply to comment #2)

If the main usecases are enterprise/deployment uses, let's discuss those when we talk about enterprise issues.

(In reply to comment #1)

I'd rather they edit firefox.js.  At that point, things like antivirus companies will flag it.

Comment 5

[Jesse Ruderman]

Some alternatives to consider:

* Change the filename we look for from "user.js" to "lockedprefs.js". That will clear up the current mess, make future mistakes less likely, and make future malice distinguishable from mistakes.

* Encourage antivirus vendors to watch for software modifying user.js.

* Prompt when we discover a user.js, asking whether the user wants to enable it. This is similar to our plan for dropped-in extensions (bug 596343).

Comment 6

[Kev Needham [:kev]]

I would advocate option #3. It's what Asa and I discussed at a high level, and the focus would be on permission to apply prefs from users.js, and a way to (simply) back out those changes for users that may be unfamiliar with them.

Comment 7

[Justin Dolske [:Dolske]]

TBH, the use cases listed in comment 3 sounds like uncommon situations we shouldn't be optimizing for. Prompting the user is also full of fail, we shouldn't be shifting the burden of dealing with lameware to the user.

The user should be in control of their browser, and so if something wants to twiddle a setting they should be able to easily revert it.

The one case I'm not sure how to handle, which obviously complicates things, is if we want to continue supporting admin-set / locked preferences, and how to do that in a way that won't just be abused by malware.

Comment 8

[Jesse Ruderman]

Another possibility, suggested by dveditz, is to make user.js only override defaults (revert bug 77975).  That would satisfy all the use cases in comment 3.

Comment 9

[Daniel Veditz [:dveditz]]

Anecdotal datapoints from add-ons:
* user.js is common enough that the SyncFox add-on backs it up.
* The "Add to NetVibes" add-on has a developer script left in the .xpi
  that recreates the developer's user.js with settings he apparently likes
  (not an active part of the add-on, just packaging cruft)

(In reply to comment #7)
> The one case I'm not sure how to handle, which obviously complicates things,
> is if we want to continue supporting admin-set / locked preferences, and how
> to do that in a way that won't just be abused by malware.

user.js was not used/intended for that, seems a separate conversation. There's a legitimate and supported method for locking prefs in the installation directory and that's where that functionality should live.

Comment 10

[Jeff Hammel]

Let's not forget our test harnesses and other infrastructure that currently utilizes user.js . This isn't a blocker, just something we can't forget (and will take many man-hours to change)

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to [:Cww] from comment #4)
> I'd rather they edit firefox.js.  At that point, things like antivirus
> companies will flag it.

Let's assume the Firefox install directory is protected because it's a limited user account -- if not all bets are off. In that situation malware won't be able to write to firefox.js, but it can easily write to prefs.js in the user's profile and the effects are mostly the same. The outcome would be better, though, because the user could manually revert those settings rather than have them come back every startup. Anti-virus can't flag on writing to prefs.js because Firefox itself does it constantly.

We should either WONTFIX this bug or take the approach in comment 8. Neither solves the list of problems in Comment 0, but at least the latter would let users who notice the problem fix it through in-product prefs. That's also the best we could hope for if we did what this bug asked (removing user.js support) so we'd at least not break people who had legitimate user.js settings.

Comment 12

[[:Cww]]

I don't see how overriding defaults actually helps anything.

The default is to block popups, the default is to use Google as a search engine, default is no proxy.  If we allow user.js to override these, we'd need a status for "default value but actually user set"

I'm going to propose a new thing: use telemetry to see what the prefs that user.js is changing are and how many people are affected. If it's 99.9% malware-y ones (as in the ones in comment 0) I think there's a strong argument for blocking it.  Otherwise, we'll discover new legit usecases for user.js.  I'm going to bring this up with taras before filing a bug but that seems like a good set of datapoints to have.