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.
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.
You don't have a damned clue how this stuff works, do you?
All the public CAs issue non-EV certificates based on the ability to control email and/or DNS information for domains, and most of them automate it. Their verification standards for non-EV certificates are on page 13 of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.7.pdf.
Let's Encrypt does exactly the same verification and meets those standards. Let's Encrypt is actually ahead of some of them in that it uses a published and publicly reviewed verification protocol (ACME) to check control over the DNS.
Yes, the CA infrastructure is shit, mostly because all you have to do to impersonate any domain is to find any CA you can trick. No, Let's Encrypt is not any worse than the hundreds of other CAs that the browsers trust.
Oh, I forgot the other major reason that the CA infrastructure is shit, which is that those verification standards are indeed too lax. If you can impersonate the server in the first place, you can probably fake control of the domain well enough to get a certificate. But again Let's Encrypt is no worse than any of the others.
I don't know about the ACME verification protocol, but stay far away from their rocket powered roller skates...
Wile E. Coyote, SG, sss. (Super Genius, still smoldering somewhat)
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
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.