5 ms·

FWIW, since the original intent of the change to block unsigned plugins was to prevent third party software installers from adding malicious plugins without use

FWIW, since the original intent of the change to block unsigned plugins was to prevent third party software installers from adding malicious plugins without user consent, leaving a preference to toggle it back would have been pretty pointless as the third party installers could have just toggled the preference themselves (about:config is just some sort of easily modifiable data format on disk). TBH it’s not hard for me to think of ways Mozilla could have preserved user control even in the face of these constraints though. For instance, I already use a master password to encrypt/decrypt the password database in Firefox. Why not allow the master password to also protect the settings and store them encrypted so a third party can’t modify them?

rightbyte 8y ago
If the malicious plugin or executable can write to disk it's probably to late anyway?
- deogeo 8y ago
  Yeah, it could replace Firefox with the developer edition that allows unsigned plugins.
- Jonnax 8y ago
  It was a significant issue for years. Mostly adware and things that replaced your default search engine.
  - the8472 8y ago
    the solution is to help users remove the adware, not centralize control over addons
- jszymborski 8y ago
  You're right, I think it just makes it less "gray". If Oracle bundles crapware with a Java installer that installs an unsigned plugin in Firefox, you can write a PR release to smooth things over. If the crapware uninstall Firefox, install Firefox Dev Edition, and installs the unsigned plugin, there's not much of a "gray" defence there.
  - the8472 8y ago
    Adware came bundled with chrome itself (for the money), i.e. installing new browsers is not out of the question here. That excuse feels really flimsy and tailored to permit only the exact choices made and no other option. But there are other options, such as helping users to get rid of adware when it's detected in the browser. It would also result in a larger benefit of improving their system instead just the browser.
    - jszymborski 8y ago
      I find my explanation more plausible than the implication that "Firefox went through the effort of making plugins required to be signed for any other reason so long as it's arbitrary or somehow malicious" that you and others seemingly subscribe to.
      - the8472 8y ago
        That's not what I am saying. I am saying that through a chain of choices they arrived at a specific conclusion how to solve their problem and then added justifications that admitted no alternatives when alternative solutions would have avoided the situation today. People, including myself, were argueing against putting mozilla in a position where they are a single point of failure. That critique was countered with the specific argument that giving users an override is not acceptable because any override could also be used by adware and thus mozilla must be the sole arbiter of what addons can be installed.
- EvilTerran 8y ago
  The malicious code may well have the necessary permissions to write to the profile folder, but not to modify the executable. Under the Unix security model, for example, that would be pretty likely: your profile's owned by your account, the executable & its containing folder are owned by root & go-w, so code running as you can tamper with the former but not the latter.
  - the8472 8y ago
    They explicitly argued with the windows threat model that installers run with admin privileges and thus can modify the program directory too. Now arguing with the unix model is shifting goalposts.
    - EvilTerran 8y ago
      Who argued that, where? I don't see it in this subthread. Regardless, as I said in my comment, I only mentioned the Unix model "for example" - not to "shift the goalposts", just because I'm more familiar with it than with whatever anti-binary-tampering measures Windows may have.
      - the8472 8y ago
        https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...
        EvilTerran 8y ago
        That very page acknowledges your concern & presents their counterargument - namely, they consider security software to be part of the Windows model, and expect that to intervene in the case of modified binaries: > By baking the signing requirement into the executable these programs will either have to submit to our review process or take the blatant malware step of replacing or altering Firefox. We are sure some will take that step, but it won’t be an attractive option for a Fortune 500 plugin vendor, popular download sites, or the laptop vendor involved in distributing Superfish. For the ones who do, we hope that modifying another program’s executable code is blatant enough that security software vendors will take action and stop letting these programs hide behind terms buried in their user-hostile EULAs. (emphasis mine)
deleted 8y ago
[deleted]
morpheuskafka 8y ago
If you have disk access, why even bother with a malicious plugin that has to follow all the plugin rules? You could just modify the executable itself and do whatever you wanted with no use visibility.
- mbrubeck 8y ago
  It's not impossible, but it's much harder to do this in a way that reliably persists through Firefox changes and updates. In comparison, changes to the prefs file are trivially persistent regardless of when and how Firefox is updated.
Fnoord 8y ago
> For instance, I already use a master password to encrypt/decrypt the password database in Firefox. This feature uses SHA-1. [1] > Why not allow the master password to also protect the settings and store them encrypted so a third party can’t modify them? It cannot protect against such. It can protect against a household adversary such as a 4 year old, and that's about it. [1] https://palant.de/2018/03/10/master-password-in-firefox-or-thunderbird-do-not-bother/ https://palant.de/2018/03/10/master-password-in-firefox-or-t...
- javagram 8y ago
  That’s disappointing to see. I had assumed it used PBKDF or something sane. Of course if Mozilla had wanted to secure the config settings they could just fix the master password hashing functionality at the same time.

rightbyte 8y ago

If the malicious plugin or executable can write to disk it's probably to late anyway?

deogeo 8y ago
Yeah, it could replace Firefox with the developer edition that allows unsigned plugins.
Jonnax 8y ago
It was a significant issue for years. Mostly adware and things that replaced your default search engine.
- the8472 8y ago
  the solution is to help users remove the adware, not centralize control over addons
jszymborski 8y ago
You're right, I think it just makes it less "gray". If Oracle bundles crapware with a Java installer that installs an unsigned plugin in Firefox, you can write a PR release to smooth things over. If the crapware uninstall Firefox, install Firefox Dev Edition, and installs the unsigned plugin, there's not much of a "gray" defence there.
- the8472 8y ago
  Adware came bundled with chrome itself (for the money), i.e. installing new browsers is not out of the question here. That excuse feels really flimsy and tailored to permit only the exact choices made and no other option. But there are other options, such as helping users to get rid of adware when it's detected in the browser. It would also result in a larger benefit of improving their system instead just the browser.
  - jszymborski 8y ago
    I find my explanation more plausible than the implication that "Firefox went through the effort of making plugins required to be signed for any other reason so long as it's arbitrary or somehow malicious" that you and others seemingly subscribe to.
    - the8472 8y ago
      That's not what I am saying. I am saying that through a chain of choices they arrived at a specific conclusion how to solve their problem and then added justifications that admitted no alternatives when alternative solutions would have avoided the situation today. People, including myself, were argueing against putting mozilla in a position where they are a single point of failure. That critique was countered with the specific argument that giving users an override is not acceptable because any override could also be used by adware and thus mozilla must be the sole arbiter of what addons can be installed.
EvilTerran 8y ago
The malicious code may well have the necessary permissions to write to the profile folder, but not to modify the executable. Under the Unix security model, for example, that would be pretty likely: your profile's owned by your account, the executable & its containing folder are owned by root & go-w, so code running as you can tamper with the former but not the latter.
- the8472 8y ago
  They explicitly argued with the windows threat model that installers run with admin privileges and thus can modify the program directory too. Now arguing with the unix model is shifting goalposts.
  - EvilTerran 8y ago
    Who argued that, where? I don't see it in this subthread. Regardless, as I said in my comment, I only mentioned the Unix model "for example" - not to "shift the goalposts", just because I'm more familiar with it than with whatever anti-binary-tampering measures Windows may have.
    - the8472 8y ago
      https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...
      - EvilTerran 8y ago
        That very page acknowledges your concern & presents their counterargument - namely, they consider security software to be part of the Windows model, and expect that to intervene in the case of modified binaries: > By baking the signing requirement into the executable these programs will either have to submit to our review process or take the blatant malware step of replacing or altering Firefox. We are sure some will take that step, but it won’t be an attractive option for a Fortune 500 plugin vendor, popular download sites, or the laptop vendor involved in distributing Superfish. For the ones who do, we hope that modifying another program’s executable code is blatant enough that security software vendors will take action and stop letting these programs hide behind terms buried in their user-hostile EULAs. (emphasis mine)

deleted 8y ago

[deleted]

morpheuskafka 8y ago

If you have disk access, why even bother with a malicious plugin that has to follow all the plugin rules? You could just modify the executable itself and do whatever you wanted with no use visibility.

mbrubeck 8y ago
It's not impossible, but it's much harder to do this in a way that reliably persists through Firefox changes and updates. In comparison, changes to the prefs file are trivially persistent regardless of when and how Firefox is updated.

Fnoord 8y ago

> For instance, I already use a master password to encrypt/decrypt the password database in Firefox. This feature uses SHA-1. [1] > Why not allow the master password to also protect the settings and store them encrypted so a third party can’t modify them? It cannot protect against such. It can protect against a household adversary such as a 4 year old, and that's about it. [1] https://palant.de/2018/03/10/master-password-in-firefox-or-thunderbird-do-not-bother/ https://palant.de/2018/03/10/master-password-in-firefox-or-t...

javagram 8y ago
That’s disappointing to see. I had assumed it used PBKDF or something sane. Of course if Mozilla had wanted to secure the config settings they could just fix the master password hashing functionality at the same time.