Hacker News Reader

Comment by Mindless2112 | Hacker News Reader

> Even better would be to set things up to only do a verify on install instead on every startup.

That would defeat the purpose of verification: "Add-on signing in Firefox helps protect against browser hijackers and other malware by making it harder for them to be installed." [1]

And it's not just malware that was doing that. Microsoft force-installed the ".NET Framework Assistant" into Firefox on Windows, and you had to edit the registry to remove it. [2] If I recall correctly, AVG and Logitech were also among the list of offenders.

[1] https://support.mozilla.org/en-US/kb/add-on-signing-in-firef... [2] https://support.microsoft.com/en-us/help/963707/how-to-remov...

View on HN

Those still would have their certificates checked on installation.

And honestly, I think it is security theater to attempt to defend against attackers on the same or higher privilege level. If microsoft wants to force something down your throat on windows then there's not much you can do.

The problem is that mozilla turns the failures of others into their own problem and then they try to fix it themselves. That scope and responsibility creep leads us to the fallout we're seeing now.

> Those still would have their certificates checked on installation.

How? These extensions were not being installed through the normal mechanism. The malicious extension installer will just set the flag that says "this extension has been verified".

> And honestly, I think it is security theater to attempt to defend against attackers on the same or higher privilege level.

I understand that, and Mozilla does too: "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." [1]

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

But that's the point. Either the installer does something malicious or it doesn't. If it does you lost the game. If it doesn't then a simple check is sufficient. Everything else is security theater which makes life worse for everyone.

Also, they could still run the verification and prompt the user instead of just forcing the decision.

I don't think that's necessarily true. After all, the policy is effective against undesirable-but-not-malicious extensions. Before signature verification I had extensions installed in Firefox that I didn't install; today I don't. [1]

And the clearly malicious action of modifying Firefox to disable signature verification can and should be flagged by anti-malware software, which runs at a higher privilege level.

[1] Putting aside for the moment the fact that most users now have no extensions installed due to the certificate expiration issue. No Firefox user, myself included, is happy about that.

I consider these to be mental acrobatics to find a position to justify wresting away any control from the user. It is not mozilla's responsibility to attempt to protect the user from the very slim line of "effectively malicious but still somehow principled" malware, picking a near-by line of verifying once would be far less problematic.

If the user does not want that crap on their machine they should remove the origin instead. We would not have the current situation if mozilla did not assume responsibility and control for problems outside their domain.

At least they could have made this opt-in by asking the user if they want an extra locked down version of firefox that might disable their addons if they are deemed malicious. Then the user could have made an informed choice.

> Before signature verification I had extensions installed in Firefox that I didn't install

... How?

I agree with the sibling poster; it sounds like you already lost.

On a typical Linux install, the Firefox binary is not writeable by a malicious extension installer that runs with user privileges. Thus baking the check into the binary fully protects the integrity.

Then overrides could also be made configurable as root.

Could you explain why verifying on every startup, instead of just on install, is necessary? The page you linked doesn't mention it.

Edit: Let me amend my question - why is it necessary for the certificates to expire? If a plugin is signed by Mozilla, why wouldn't it be trusted once it gets old?

There’s no guarantee that a (malicious or undesirable) extension was added via FF, so check on install could be circumvented by any of the crapware installers we all love.

How do you propose Firefox should tell whether the unsigned, shady add-on was installed by the user, or by some other dodgy app messing with Firefox's files whilst it wasn't running to make it look like the user installed the add-on?

> Let me amend my question - why is it necessary for the certificates to expire? If a plugin is signed by Mozilla, why wouldn't it be trusted once it gets old?

I asked essentially that question earlier, and received some good answers explaining why [1].

Briefly, if something is signed by an expired certificate, whether or not you can trust the signature depends on whether or not the signing took place while the certificate was not expired.

If all you have is the thing and the signature from the code signer, you can't tell for sure when it was signed. If a bad guy has obtained an old signing certificate and its keys, that bad guy can generate new signatures that claim to have been signed while the certificate was valid.

Some code signing systems, such as the one in Windows (and I think the one Apple uses) also use another certificate, from a timestamp service, to prevent this. The way a timestamp service works is you send them a hash of a document, and they generate a certificate signed by them that essentially says "We were shown this hash on this particular date/time".

When you include the timestamp certificate with the signature from the code signer, then when you come across code that was signed by an expired certificate but purports to have been signed while the certificate was still valid, you can check the timestamp certificate to see if that is true. If it is, you can still consider the code signing to be valid.

Forgetting to renew a signing certificate is still bad even if you do this, but not as bad. If Microsoft or Apple forget, it doesn't stop existing applications from working, so end users aren't immediately impacted. It does stop developers from shipping updates or new applications, so still would be a big deal. I could see a bad guy noticing that a company always updates expiring certificates one month in advance, say, and then noticing that a certificate is expiring in just a week, infer that the certificate renewal has slipped through the cracks and is going to expire, and time the use of a critical zero day exploit to fall in the window when updates are broken by the expired certificate.

[1] https://news.ycombinator.com/item?id=19824017

I checked the hash functions for the xpi, its broken MD5 and broken SHA... which doesn't matter for a running instance if FF takes care to download it from their own servers over HTTPS... but in the attack model you describe it is retrieving the signatures from an untrusted disk.

https://news.ycombinator.com/item?id=19830228

> And it's not just malware that was doing that. Microsoft force-installed the ".NET Framework Assistant" into Firefox on Windows, and you had to edit the registry to remove it.

If it's not a malicious extension, verifying the signature doesen't prevent a forced install.

Reply on news.ycombinator.com