[BreachExchange] The Great (belated) Mozilla Firefox CVE Dump

[Inga Goddijn]

https://www.riskbasedsecurity.com/2018/06/the-great-belated-mozilla-firefox-cve-dump/

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180613/3422a1aa/attachment.html>