The Great (belated) Mozilla Firefox CVE Dump

[This was originally published on]

On June 11th, MITRE published descriptions and references for 318 entries, all  relating to Mozilla Firefox. Yes; three hundred and eighteen entries. It may be tempting to think Mozilla was holding back on disclosures or there was a flurry of research activity leading to a slew of new vulnerabilities being discovered. But no, this would not be the case. These disclosures are an example of what happens when a backlog of reserved CVE IDs are finally processed and published. In fact, some of these CVE IDs have been reserved for as long as 4 years, with two issues tied to third-party library vulnerabilities that have been known since 2011. 

This means that for the last two years or more, CVE has had no public details on any Mozilla Firefox vulnerabilities, despite these issues being made public on Mozilla’s web site with each new release of Firefox. Any company relying solely on CVE for vulnerability intelligence on Firefox simply did not have it.

Among the Firefox vulnerabilities were over a dozen issues from the third-party libraries used by Firefox and Thunderbird. The culprits include:

  • Google Skia (4)
  • ANGLE (3)
  • Graphite (2)
  • Cairo
  • Expat
  • HarfBuzz
  • Hyphen
  • Libvpx
  • Libvorbis / libtremor
  • Freetype

While not exactly household names, these libraries are used in a wide variety of well-known products including Android, Samsung devices, Google Pixel devices, VM Server, Pivotal Application Service, XEROX printers, IBM Scale Out Network Attached Storage (SONAS), IBM PowerKVM, Micro Focus iPrint Appliances, AlienVault OSSIM, AlienVault USM, Symantec SSL Visibility, Python, Apple iOS, and macOS / Mac OS X.

To put the Firefox vulnerabilities included in the CVE dump into better perspective, we refer to VulnDB’s VTEM (Vulnerability Timeline and Exposure Metrics). Looking at Firefox, and narrowing the disclosure history to 2016 – 2018, it paints a more complete picture of what their vulnerability history actually looks like. The first thing to jump out is that we track 890 vulnerabilities vs the ~ 300 CVE included. This is due to CVE’s practice of lumping multiple unique vulnerabilities into a single entry, as well as missing some disclosures completely. The VTEM also shows the average CVSS score, average time to patch, and much more. Imagine missing this many vulnerabilities in a two year period for a single product. Organizations relying on CVE don’t have to imagine it unfortunately.

Not to be overlooked, the dump included another important disclosure; the OpenPGP / S/MIME vulnerability known as ‘Efail’ – which garnered huge press and dire warnings from the Electronic Frontier Foundation – was present. While the severity of Efail is a hotly debated topic, it is still critical to know about such issues so that your organization can evaluate the risk in the context of your systems and users.

When it comes to vulnerability intelligence, timeliness is critical. Getting information on a given vulnerability days, weeks, or even years late can leave organizations needlessly exposed to attackers. In this case, CVE delivered information on 318 vulnerabilities up to seven years late. Compare that to VulnDB, which had information on all of these issues available immediately after disclosure, including additional technical details still not available in some of the CVE entries. Timely, high quality vulnerability intelligence is the only way an organization can properly evaluate the risk, triage the constant flood of new vulnerabilities, and better protect their organization.

Leave a Reply

%d bloggers like this: