Hacker News Reader

Comment by rightbyte | Hacker News Reader

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

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.

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.

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.

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.

It was a significant issue for years. Mostly adware and things that replaced your default search engine.

the solution is to help users remove the adware, not centralize control over addons

Yeah, it could replace Firefox with the developer edition that allows unsigned plugins.

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.

The malicious code can simply write an executable somewhere in the profile (or /tmp, or anywhere). It is highly unlikely that the profile (usually in /home/${USER}/) is on a filesystem mounted with the "noexec" flag.

Or just inject code the browser at runtime.

Under the Unix security model, the UID is the permission boundary. Even if the binary is owned by root, it inherits the user's UID when they run it.

Well, true, but all this is a lot more conspicuously fishy than "flip a setting that the user might have legitimately flipped themselves". You're not going to get far hiding a whole new Firefox install in $HOME before someone asks why theirs suddenly got 200MB bigger, for one thing.

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.

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.

https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...

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)

Replacing FF stable with FF dev edition would not constitute modifying the program, it's installing a new browser. A lot of installers shipped chrome, this was even encouraged by google. So I do not think this addresses the issue.

In reality though, this change has been live for a year. How many of the malicious actors switched to the model of uninstalling Firefox Stable and installing Firefox Developer Edition? (And presumably updating all the user’s aliases, start menu items, etc to point to the new browser).

I haven’t heard of this actually happening.

"attack widely known and observed in the wild" is usually not the bar by which computer security systems are measured.

Mozilla’s thesis is that attackers wouldn’t be willing to go to this next step (actually uninstalling Firefox and replacing it with a different binary) because antivirus vendors would start treating them like malware.

In other words, it’s not a purely technical solution, it’s a political solution, and the success or failure of such a political solution can only be judged by real world results rather than technical possibility.

Reply on news.ycombinator.com