Ancient CVEs Can Cause You Problems

By Kent Landfield · September 23, 2022

The Common Vulnerability and Exposures (CVE) Program was founded in 1999 for the purpose of giving individual cyber vulnerabilities an identifier that could be used as an interoperable means for identifying a specific vulnerability. Today CVE is used in all aspects of vulnerability identification and reporting. There is an urban myth that if there is a CVE issued, there is a fix associated. Yes, I have heard that many times over the years. That, however, is NOT the case. CVE’s are simply there to provide a common identifier for a specific vulnerability. It is up to the software publisher responsible for the software to decide to develop a remediation or patch to fix the problem.

Today, too many organizations are relying on the Common Vulnerability Scoring System, developed at FIRST.org, to decide when it is time to patch. Often the decision is to defer fixing until later, only to be overcome by events or forgotten. CVSS is a 0 to 10 scoring of a specific vulnerability. Sadly, vulnerability management programs rely too heavily on the CVSS Base score, produced by vendors and the National Vulnerability Database, in determining the severity and impact of the vulnerability on their operational practices. Vulnerability Management teams often rely solely on the CVSS score assigned to a specific CVE to decide whether or not to fix the CVE in their environment. The CVSS severity thresholds are as follows.

• 0 = None
• 0.1-3.9 = Low
• 4.0-6.9 = Medium
• 7.0-8.9 = High
• 9.0 - 10.0 = Critical

What we have seen over the years is organizational vulnerability management teams map these scores directly into the remediation processes they follow. Vulnerabilities with a Low CVSS score are often ignored completely, Medium are quite often deferred to another time, while a vulnerability with a 7.0 and above generates a hair-on-fire “patch now” event.

I challenge anyone to tell me the operational impact difference between a 6.8 and a 7.0…

It has been known for more than a decade that malicious actors reverse engineering patches published by product vendors, on the day they are released, in order to determine the exact vulnerability / attack vector the patch was closing. They then incorporate these into their attack toolsets to better automate their ability to penetrate accessible organizational systems. They do not care if it was a low, medium or high vulnerability, as long as it achieves their goals. The problem is they have numbers on their side. If every single company, organization, government, and individual system applied the patch the day it was issued then this would have made reverse engineering operations a waste of time. But that was never the case and continues not to be the case today. Patches just don’t get applied in a timely fashion. ADVANTAGE MALICIOUS ACTORS!

This issue has not been just a product’s end-customer operational consideration. Software publishers have also fallen into this CVSS mindset. In the past, both in open source and the commercial development, we have seen a lack of urgency for the developer to fix a low to medium vulnerability. All too often CVEs with CVSS scores not considered important enough to fix at the time, were deferred until a later date or never fixed at all in the source.

Recently Trellix’s Advanced Research Center (ARC) team discovered the directory traversal vulnerability (CVE-2007-4559) still exists in the Python tarfile module being actively distributed and used globally today. Note the -2007- element of the CVE ID stands for the year the CVE was issued. This is a 15-year-old vulnerability not considered important enough to fix at the time. It is now found extensively across the internet in frameworks used by AWS, Facebook, Google and Netflix, and just about any site running Python.

At this point, fixing this CVE, whose CVSS score is 6.8, is much more complex, expensive and time consuming. Again, I challenge anyone to tell me the operational impact difference between a 6.8 and a 7.0…/p>

If CVE-2007-4559 were only an exception….

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) recently ordered federal agencies to patch a set of vulnerabilities that were just added to the Known Exploited Vulnerabilities (KEV) catalog. Of the six vulnerabilities recently added to the KEV, four had CVEs assigned in 2013 and one in 2010.

The Binding Operational Directive 22-01-Reducing the Significant Risk of Know Exploited Vulnerabilities issued in November of 2021 requires agencies to remediate vulnerabilities identified and added to the KEV.

If you are one of the organizations that bases their patching decisions on CVSS scores, do yourself a favor, subscribe to the KEV updates and add fixing those listed in the KEV catalog a priority in your vulnerability management process. It will be a positive step in the right direction.

It is time we reexamine each of our vulnerability management programs to assure we are not letting impactful and known CVEs continue to exist in our networks long past the time that vendor fixes are available. We need to evolve our practices to incorporate capabilities such as KEV into our operational vulnerability analysis decision making.

We keep making it too easy for malicious actors to cause us harm. You can do something about your own risks regardless of whether you are a software publisher or an end-user. Make the bad actors have to work harder. If you do, they may just pass by your systems for easier targets to compromise elsewhere.

_ This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers. _

_ This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers. Trellix conducts research in accordance with its Vulnerability Reasonable Disclosure Policy. Any attempt to recreate part or all of the activities described is solely at the user’s risk, and neither Trellix nor its affiliates will bear any responsibility or liability. _