Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

10/14/2015
12:00 PM
Rob Tate
Rob Tate
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

'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.

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:

  1. Lots of applications affected 
  2. Lots of attention at executive/board level 
  3. Lots of media coverage 
  4. 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.  

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.

Rob Tate serves as the senior manager for WhiteHat Security's Threat Research Center. In this role, Rob researches emerging threats and how businesses can successfully protect themselves against vulnerabilities. Before focusing on research, Rob began at WhiteHat as an ... View Full Bio
 

Recommended Reading:

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
How to Identify Cobalt Strike on Your Network
Zohar Buber, Security Analyst,  11/18/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: A GONG is as good as a cyber attack.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15246
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.421 and before version 1.0.469, an attacker can read local files on an October CMS server via a specially crafted request. Issue has been patched in Build 469 (v1.0.469) and v...
CVE-2020-15247
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, an authenticated backend user with the cms.manage_pages, cms.manage_layouts, or cms.manage_partials permissions who would normally not be permi...
CVE-2020-15248
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.470, backend users with the default "Publisher" system role have access to create & manage users where they can choose which role the ...
CVE-2020-15249
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, backend users with access to upload files were permitted to upload SVG files without any sanitization applied to the uploaded files. Since SVG ...
CVE-2020-28927
PUBLISHED: 2020-11-23
There is a Stored XSS in Magicpin v2.1 in the User Registration section. Each time an admin visits the manage user section from the admin panel, the XSS triggers and the attacker can able to steal the cookie according to the crafted payload.