This weekend news emerged that the Mozilla Foundation's Bugzilla tracker's hoard of vulnerabilities in the Firefox web browser had been breached for more than a year and potentially as long as two years. By Mozilla's own admission critical security vulnerabilities left unfixed for months had been available to the breaching party who had complete access to a goldmine of ways to abuse Mozilla users that Mozilla itself had been sitting on. Mozilla's handling of this episode has been nothing short of abusive to its users.
The one vulnerability Mozilla will confess to having been exploited in the wild was a catastrophic bug in their built in pdf display tool pdf.js1 which allowed attackers serving malicious pdfs to take all of the most valuable information off of the affected user's machines.
Mozilla's greatest evil in this entire episode was neglecting to carry out the only actual remedy for this situation which would have showed any respect for their users. They did not upon discovering the compromise of their vulnerability hoard inform users to stop using their actively compromised browser. Instead they shut down the account on the Bugzilla system which was known to be compromised, burned a lot of time on forensics including an audit by a third party, and they did everything except inform their users that they needed to stop using Mozilla Firefox. Instead they insist everything is better, that they patched everything back on August 27th, and that we shouldn't care about how grave the problems patched were until more than a week later.
This is nothing less than actual Microsoft level contempt and abuse of Mozilla's userbase. If Mozilla was being operated by people of integrity instead of Chairwoman Mitchell Baker, Executive Director Mark Surman, CEO Chris Beard, General Counsel Denelle Dixon-Thayer, and other guilty parties they would have made the decision to dissolve as an ongoing concern. Instead a FAQ was published as a PDF document, the text of which has been preserved here for posterity.2
Of course this ignores the glaring idiocy of writing a pdf viewer in javascript and embedding in the web browser as the default viewer when security issues aside, the result is a slow poorly performing piece of shit compared to every other alternative. As an example evince could have been embedded instead if Mozilla insisted on a pdf viewer. If distributing a web browser that requires compiled code to run there is no reason to use slow javascript to handle complex pdf documents. Someone actually chose to do extra work to make their user experience worse than it would have been otherwise. ↩
A particularly poor choice given the nature of the publicized vulnerability from the batch Mozilla was sitting on. Here is the full extracted text from the FAQ PDF:
Improving Security for Bugzilla Frequently asked questions What happened? Bugzilla restricts access to securitysensitive information so that only certain privileged users can access it. An attacker was able to break into a privileged user’s account and download securitysensitive information about flaws in Firefox and other Mozilla products. How did the attacker gain access? The attacker acquired the password of a privileged Bugzilla user, who had access to securitysensitive information. Information uncovered in our investigation suggests that the user reused their Bugzilla password with another website, and the password was revealed through a data breach at that site. How long did the attacker have access? The earliest confirmed instance of unauthorized access dates to September 2014. There are some indications that the attacker may have had access since September 2013. What immediate actions has Mozilla taken? Upon discovery of the unauthorized access, Mozilla’s security team shut down the compromised account and began to assess the scope of the information that was available to the attacker. We conducted audits of several other systems to look for other evidence of compromise. We also worked with an outside security firm to conduct forensic analysis. What else has Mozilla done to prevent it happening in the future? We are taking several steps to be more restrictive in who can have access to securitysensitive information in Bugzilla and how they can access it. First, we are making it harder to break into Bugzilla accounts. Passwords have been reset for all privileged users, and going forward, all privileged users will be required to use twofactor authentication to log into Bugzilla. Second, we are reducing the access that each Bugzilla user is granted in order to limit the amount of information that could potentially be exposed in the event of unauthorized access. Third, we are increasing the amount of auditing we do on the actions of privileged users so that we can detect suspicious activity more quickly and accurately. What security information did the attacker have access to? Bugzilla tracks information in units of “bugs”. Each “bug” in Bugzilla typically represents a single flaw to be fixed, or a single improvement to be made. Bugzilla’s logs allow us to see exactly which bugs the attacker accessed and when. Overall, the attacker accessed 185 nonpublic bugs, distributed as follows: 110 bugs Protected for reasons other than software security (e.g., proprietary information) 22 bugs Minor security issues (seclow or secmoderate) 53 bugs Severe vulnerabilities (sechigh or seccritical) Of these 53 sechigh or seccritical bugs, 43 had already been fixed in the released version of Firefox at the time the attacker found out about them. The information in those bugs likely could not have been used to attack Firefox users. For the remaining 10 bugs, the attacker had some window of time between when the bug was accessed and when it was fixed in Firefox: 2 bugs 5 bugs 3 bugs Less than 7 days Between 7 days and 36 days More than 36 days (131 days, 157 days, 335 days) It is technically possible that any of these bugs could have been used to attack Firefox users in the vulnerability window. One of the bugs open less than 36 days was used for an attack using a vulnerability that was patched on August 6, 2015. Other than that attack, however, we do not have any data indicating that other bugs were exploited. What impact has this had on Firefox users? The largest known impact on users is through the vulnerability we fixed on August 6th. We know that an attack exploiting that vulnerability was used to collect private data from Firefox users visiting a news site in Russia. There is no indication that any of the other bugs the attacker accessed have been exploited. How can Firefox users protect themselves? The best way for users to protect themselves is to run the latest version of Firefox. On August 27, we released new versions of desktop Firefox, Firefox for Android, and Firefox ESR. These versions address fixes all of the vulnerabilities that the attacker learned about and could have used to harm Firefox users.
> Instead a FAQ was published as a PDF document
Well how else do you expect them to exploit that unfixed PDF-rendering bug?
gbang0wn3d