Apple, Microsoft, Google Attacked For Evil Plugins

nk497 writes "A Mozilla exec has attacked Apple, Microsoft and Google for installing plugins without users' permission. 'Why do Microsoft, Google, Apple, and others think that it is an OK practice to add plug-ins to Firefox when I'm installing their software packages?' Asa Dotzler asks. 'That is precisely how a Trojan horse operates... These additional pieces of software installed without my consent may not be malicious but the means by which they were installed was sneaky, underhanded, and wrong.' He called on them to 'stop being evil.'"

Comments

Yes

[metrix007]

Yes...I should not have to check addons to firefox to make sure nothing dodgy has been installed. Of course, this behaviour will continue as long as it is technically possible, so why doesn't Mozilla simply make it impossible? Only allow installing addons through firefox, with explicit prompts.

Re:Yes

[Krneki]

Exactly, lock the plug-ins with a password. This is something I'm waiting since a long time ago.

It's my browser and I don't like changes being made without my explicit confirmation.

Re:Yes

[mellon]

You are right in principle, but not in practice. The problem is that the security model for software package installations allows for privilege escalation in an unconstrained (not chrooted) environment. This means that the installer can do whatever it wants to Mozilla, and there's nothing Mozilla can do to stop it.

The solution to this problem is to use a different installation model and a different security model. Two examples are Bitfrost and iOS. Both use a security model where apps are constrained as to what they can access, and how they can access it. Installers aren't allowed to scribble all over the filesystem. Consequently, app installers would not be *able* to modify the Mozilla install, so this simply wouldn't be an issue.

So basically what's going on here is that these companies are taking advantage of a broken security model while they can. Hopefully as technology marches forward, this broken security model will become obsolete, although I see no evidence that Microsoft or Apple are working on it.

Re:Yes

[QuoteMstr]

This approach is doomed.

The browser has to somewhere remember that a user approved an extension. It does this by writing state to disk. A malicious extension installer can simply modify this saved state to make the browser think the user installed and approved the payload. The same goes for a startup message advertising extensions that have been installed since the last browser run.

You can't win this fight without OS involvement. The correct solution is application-level sandboxing, which quite a few people are working on.

Re:Yes

[Corporate Troll]

True, but keep in mind that only a privileged user would be able to install anything that has such a payload. So... Not a problem.

Re:Yes

[The Moof]

It also doesn't help stealth plug-in installations. Not to mention Firefox has no method to remove installed plug-ins, only disable them. Mozilla's official method is to hunt down the file on your system and delete it.

Needless to say, Mozilla's Plug-in handling leaves a lot to be desired.

Re:Yes

[QuoteMstr]

Encrypt the list of enabled plugins with a user password

"Encryption" is the wrong word here. What we're talking about is digital signing. The way it would work is that upon installation, the browser would generate a public-private keypair, encrypt the private key with a password of the user's choice, and save the resulting public key and encrypted private key to persistent storage.

At all times, the browser would store the list of enabled plugins and sign it with the encrypted private key. Nobody can generate a valid signature for a list of enabled plugins without the password, and the browser will not use a plugin list unless it comes with a valid signature.

All this is fine as far as it goes, but it'll only work until our malicious plugin installer patches the browser binary and makes it skip the key check; the malware could also replace both the public and the private key with replacements of its choosing. Either way, the user may or may not eventually notice that something is wrong, but if he does, it probably won't be a while, and he probably won't be able to track the malfunction back to the evil installer.

Malware vendors can also wait for the user to type his password when installing a different plugin, then use that password to generate a valid signature for a plugin list that includes anything desired.

The moral is that applications still need to be sandboxed. They're not protected from each other. Without OS-level protection, applications can do horrible things (often without needing elevated privileges at all). Half-measures aren't the answer.

Re:Yes

[QuoteMstr]

My interpretation was in the spirit of intellectual charity, not arrogance; i.e., I gave you the benefit of the doubt, employing the only interpretation that makes any sense.

Encryption without authentication is worthless. Either you're using symmetric encryption and you make the user enter the password every time the browser wants to read the plugin list (or worse, store the key on disk), or you're using asymmetric encryption and creating a message that can be decrypted by a given public key is simple.

Encryption *and* authentication is pointless in this case because the browser needs to be able to decrypt plugin information at all times using only information in persistent storage. Encryption does not provide any security properties in this context.

So we're left with authentication itself being the task at hand, which I assumed is what you meant. But instead of having an adult conversation about the issue, you have a temper tantrum. I'm through.

Solution: Warning box

[GodWasAnAlien]

Warning: A third party plugin, PluginNameHere, has been installed without user consent:

DELETE KEEP

Don't stop them from adding, auto remove...

[gurps_npc]

Not that difficult to code in a startup screen "X addons installed since last restart. Should I remove?"

And

[ISoldat53]

Make it easier to remove them.

Re:people don't seem to mind

[spacefiddle]

I would alter "do not mind" to "have no clue and don't understand the potential implications of." The end result will be a highly controlled everything, because people are neither taught nor encouraged to think about things that don't relate to their immediate button-pushing responsibilities, coupled with a fair amount of casual despair about having any control over their own lives.

Most enduser types I've talked to about such things tend to give me lines like "Ah, none of this stuff affects me," "Whaddyagonna do, they'll do what they want anyway" and "Pfff, they wouldn't do anything really bad."

Re:So because Mozilla's security model is flawed

[Lundse]

Yes. It is the other's fault.

The human body is very easy to puncture with a knife, this does not make slashing open your neighbour OK.
Cars can drive beyond the speed limit, houses can be broken into, people can be swindled, telephones called by telemarketers, etc. etc.

None of this makes it OK to do any of these things, and just because Firefox is built around a certain design principle (that it should be easy to modify) does not make it OK for others to modify it against the user's wishes.

Re:people don't seem to mind

[Anonymous Coward]

The CAPTCHAs are themed to the article. Slashdot has been doing this for a long time now. People like you keep posting their CAPTCHAs as if it is some humorous and unlikely coincidence that the word has a contextual applicability to the article topic.

This is on purpose. The system is explicitly designed to do this. Stop acting surprised.

Doomed to failure.

[davev2.0]

This solution requires Mozilla to fix things on their end rather than complaining about big companies doing something Mozilla didn't bother to prevent.

Java has quirks.

[Futurepower(R)]

Java has ALWAYS been a badly managed language. Sometimes programs (not web sites) will only run correctly with an old version of Java.

Those who supply Java programs often have to deliver an entire Java run-time package to make sure their programs will run.

The quirky management of Java was extremely strong public relations for Sun. Notice that Sun no longer exists.

Re:Java has quirks.

[bberens]

I recall the day when Sun released a new patch for Java. Everyone auto-updated and all of a sudden the transparency of labels in our app was broken all over the place. Luckily for us there were only a hand full of people using our app on a Windows desktop OS (most are CE). So rather than going back and redoing the layout for all of our screens we just handed people a functioning JRE. That was an annoying day when a bug was introduced into our app by the platform vendor.