Slashdot Mirror
Mozilla Checks If Firefox Is Affected By Same Malware Vulnerability As Tor (arstechnica.com)
Mozilla is investigating whether the fully patched version of Firefox is affected by the same cross-platform, malicious code-execution vulnerability patched on Friday in the Tor browser. Dan Goodin, reporting for ArsTechnica: The vulnerability allows an attacker who has a man-in-the-middle position and is able to obtain a forged certificate to impersonate Mozilla servers, Tor officials warned in an advisory. From there, the attacker could deliver a malicious update for NoScript or any other Firefox extension installed on a targeted computer. The fraudulent certificate would have to be issued by any one of several hundred Firefox-trusted certificate authorities (CA). While it probably would be challenging to hack a CA or trick one into issuing the necessary certificate for addons.mozilla.org, such a capability is well within reach of nation-sponsored attackers, who are precisely the sort of adversaries included in the Tor threat model. In 2011, for instance, hackers tied to Iran compromised Dutch CA DigiNotar and minted counterfeit certificates for more than 200 addresses, including Gmail and the Mozilla addons subdomain.
While it probably would be challenging to hack a CA or trick one into issuing the necessary certificate for addons.mozilla.org
That depends on the CA, some are more easy to trick than others...
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
Linux desktop? Check.
GIMP image editing? Check.
Firefox web browser? Check.
Open source == fail.
...then EVERY OS and APP has been a failure.
And in case of Mozilla it isn't even needed. The idiots have full trust to "let's encrypt" by default, and if you haven't paid attention the no script site is with a completely broken certificate by let's encrypt as well.
The idiots behind let's encrypt don't understand that the first and role of the public CA system is identity non-repudiation, but they issue certificates with any name to anyone who asks.
The the idiots at Mozilla decide to add let's encrypt to the trusted list by default completely braking their browser identity validation.
Screw encryption, why would I need something encrypted if I have zero guarantee that the other endpoint is who it is claiming to be!? If I have no trust who the other party is, encryption makes zero difference, sine there will be 0 data exchanged.
End of story.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Let us know when you find something out...
My eyes reflect the stars and a smile lights up my face.
That's all you had to mention.
The whole F-ing CA model is broken beyond repair...
Can we get rid of this joke of a model that we're all relying upon for the rest?
Still don't like it.
Someone with a forged certificate can impersonate a web site. This is not a vulnerability, this is a feature of the threat model: we blindly trust CA for issuing only legitimate certificates.
This weakness in the security model can still be addressed, because fortunately we already have a workaround for it: HTTP Public Key Pinning (HPKP).
Who brought in the australis and pocket vulnerabilities.
Replace it with time.
You keep the same cert and same key for a site and it never expires, ever. You know its the correct cert, because it was for a last gazillion times you accessed the site. To attack such a system, a MITM attacker would have to catch each and every access you ever made to that site. And even go back in time and catch all the accesses back to the very first. If they fail to catch one access, then the key signature changes and you are alerted to the man in the middle attack.
How do you verify the very first connection? You don't, because you have no way of knowing this is the very first connection to that site, you have no way of knowing if you man in the middle that site without setting off alarms.
As it is with certificates, you access a site and a third party says "yeh sure its legit". In the process you're filing the NSA's meta database with details of your access to that site, and giving them an opportunity to substitute a fake 'yeh sure its legit' message.
Look in your browser, you're adding LOTS OF COUNTRIES spooks controlled registrar to the list. Now that Russia has the keys for all its registrars, it has the ability to fake certs for every browser that has one of those registrars as trusted. So all of their registrars are compromised and so is the certificates system as a whole.
US certificate system is known to be malicious (Symantec's Thawte subsid was caught issuing fake certs, Symantec handed fake cert powers to BlueCoat, Symantec control 70% of the cert market). We know from Snowden, NSA was issuing fake certs to man in the middle Google.
Consider a simpler example: I have a local server NAT side, it has a self cert. My browser warns of the 'bad' cert (Firefox is a piece of shit in its handling of self signed certs). To fix that warning I would have to register the cert with an outside registrar so it could 'verify' the cert. And in the process it could verify any fake cert it wants as also true and I am also handing it information each time I access MY server from MY computer.
Certificate authorities are more bad than good at this point.
HPKP carries a massive DoS risk that cannot be mitigated if you suffer a breach of key, sabotage, or a simple operational error.
It would be much better if we could use HPKP to pin the last-level CA (as an alternative to what HPKP already allows). Microsoft, Mozilla, Google, Opera, etc. are quite capable of deploying restricted-use CAs if they had a reason to. In fact, at least three on that list already do.
Meh, never mind. You can do exactly that already (pin the root or an intermediate CA).
So, yeah, it is mozilla's own fault that they are not doing things properly and operating a CA in a free country (certainly not the USA or anywhere with secret courts) and HPKP-pinning that.
Surely signing extensions and signing software updates use two different certs and either cert is uses the existing HTTPS SSL/TLS CA system for that ?
Mozilla are a company that clearly deals with and understand X.509 certificates, so surely anything they do themselves where they control both the distribution and verification they use their own CA.
The only purpose of the "trusted CA" system is to issue certificates where there are three parties involved, a mutually trusted CA, a server (that needs to verify its legitimacy) and a client (that needs a mechanism to verify the servers legitimacy). But there is only 1 party involved with Mozilla extension and Mozilla browser software updates (although thats not completely true to OS vendor might also be involved for OS level code signing).
So while the might use HTTPS under that system, the payload it carried is also signed right ? And that verification process is using a CA system that only Mozilla control ?
HPKP carries a massive DoS risk that cannot be mitigated if you suffer a breach of key, sabotage, or a simple operational error.
True. If someone manages to spoof your server's response, an evil HPKP header can be sent so that your server will not be reachable anymore. The best protection against this is to implement HPKP on your server, so that the evil HPKP header cannot be accepted.