'POODLE' One Year Later: Still Around? Not So Much
As high-severity vulnerabilities go, POODLE remediation rates and times have proven to be astonishingly better than expected.
It’s been a year since the original version of the POODLE vulnerability hit the news. Since then, there have been several new incarnations keeping this SSL/TLS issue alive in the nightmares of IT professionals and vendors everywhere.
The ones we have the most data on are the original (CVE-2014-3566) and the “POODLE TLS” (CVE-2014-8730 and others), which we internally nicknamed “Zombie POODLE.” Note that while CVE-2014-8730 should technically only be used for F5, in practice it was used to refer to many implementations of TLS 1.x.
True, people are still vulnerable to this issue, as raw lifetime stats for two vulnerabilities show:
Table 1: A DOG'S LIFE
Original POODLE | POODLE TLS | |
Total Found | 13610 | 1887 |
Currently Open | 2983 | 553 |
Currently Closed | 10593 | 1325 |
% Closed | 78% | 70% |
Average Time-to-Fix | 34d 16h | 67d 7h |
But, as regular readers of our annual stats report know, even for high-severity issues, these remediation rates and times are astonishingly good.
Fixed so fast
Here is the trend of remediation for POODLE, and for comparison CVE-2012-1823, another severe vulnerability, but one that did not have a big impact from a public perception perspective. When comparing remediation, I like to graph the remediation time distribution. The Y-axis here is number of distinct vulnerabilities closed with a time-to-fix in the range on the X-axis.
Figure 1:
Figure 2:
The CVEs above are both severe and well-known issues to application security professionals. That’s partly because both vulnerbailities were exploited frequently. But even very common, severe issues like XSS and SQLi do not get the quick response we saw with POODLE. The overall curve is generally true of severe issues: Most of the vulnerabilities that are closed are done so pretty quickly. But the average remediation time for the PHP bug is 106 days vs. POODLE’s 35.
In my opinion, there are four inter-related reasons why POODLE was addressed so quickly:
Lots of applications affected
Lots of attention at executive/board level
Lots of media coverage
Lots of vendor attention (and patching)
What’s in a name?
Beyond the above list, it’s entirely possible that giving this vulnerability a name was the most important factor, more so than the fact that it actually affected large numbers of sites. Giving widespread vulnerabilities names has become a trend in the security industry and while some have proven to be overhyped, it’s at least gotten the security conversation into C-level and boardroom discussions.
Google Trends offers a graphical illustration of public interest over time, based on a world wide web search on the CVEs from January 2012 to November 2015.
Figure 3: View full Google interactive graphic.
No two issues are exactly alike, nor are the circumstances around their coverage. However, I think it’s safe to say that coming on the heels of Shellshock and Heartbleed -- and having a memorable name -- had a big impact on the short time-to-fix for P00DLE.
Related Content on POODLE:
'POODLE' Attacks, Kills Off SSL 3.0
A newly discovered design flaw in an older version of SSL encryption protocol could be used for man-in-the-middle attacks -- leading some browser vendors to remove SSL 3.0 for good
Crypto In The Crosshairs Again
"POODLE" attack extends to newer versions of SSL/TLS encryption as well.
4 Infosec Resolutions For The New Year
Don’t look in the crystal ball, look in the mirror to protect data and defend against threats in 2015.
FUD Watch: The Marketing Of Security Vulnerabilities
I’m all for raising awareness, but making designer vulnerabilities, catchy logos and content part of the disclosure process is a step in the wrong direction.
About the Author
You May Also Like
Cybersecurity Day: How to Automate Security Analytics with AI and ML
Dec 17, 2024The Dirt on ROT Data
Dec 18, 2024