In the cybersecurity domain, we often assume that regularly checking for and applying updates keeps our systems secure. However, a subtle nuance is frequently overlooked. When we say we’ve applied “all available patches,” what we’re really saying is we’ve applied all patches “provided by our distribution vendor.” And therein lies the potential pitfall; complete coverage isn’t always guaranteed.

Deciphering the CVE Scoring Game

CVE scoring can be perplexing. Experts often differ on how they rate a given vulnerability, leading to a subjective approach to vulnerability and risk analysis. Such subjectivity can cause vulnerabilities to be either overestimated or underestimated in terms of their potential threat. 

With the forthcoming CVE scoring system version 4.0, an attempt is being made to reduce this subjectivity. Still, the issue remains: software vendors sometimes adjust or disregard official CVE scores, leading them to decide not to release patches for particular vulnerabilities. This inconsistency can leave users vulnerable. Additionally, the score a CVE gets will determine the applicability of different compliance requirements around its patching.

Compliance ≠ Security

Merely patching software to meet compliance standards doesn’t equate to a genuinely secure environment. The bureaucratic nature of compliance often lags behind the rapidly evolving threat landscape, leaving systems at risk.

Not having patches for a given vulnerability only compounds the illusion of security that you get when you patch to meet compliance requirements. Your security compliance report can be spotless – you patched everything you had patches for – but your system still has numerous security flaws.

But I Get My Patches from a Reputable Vendor

Another common misconception is that sourcing patches from reputable vendors guarantees security. However, our research revealed numerous instances (hundreds) where Red Hat did not release patches for critical vulnerabilities in its RHEL 7 or CentOS 7 operating systems, despite them still being under official support. Examples include:

CVE-2023-2953 (7.1 CVSS v3.1, Red Hat Score 7.1): A vulnerability in OpenLDAP, a widely-used centralized identity management platform. Red Hat’s stance: will not fix.

CVE-2023-27534 (8.8 CVSS v3.1, Red Hat Score 3.7): A flaw in curl’s handling of path traversal when accessing SFTP resources. Red Hat’s stance: will not fix.

CVE-2022-1292 (9.8 CVSS v3.1, Red Hat Score 6.7): A script issue in OpenSSL that also affects packages like MySQL. Red Hat’s solution: fixes available only for versions 8 and 9. Note that there is readily available proof-of-concept exploit code accessible with minimal effort on the Internet for this particular vulnerability.

And many other CVEs follow this line.

It is noteworthy that Red Hat sometimes assesses vulnerabilities as having a lower score than the original NIST CVE scores. A lower score means that a certain flaw no longer fits into a certain risk tier (i.e., critical, high, medium, etc.). This doesn’t make the vulnerabilities any less dangerous. It only makes them unpatched.

Red Hat’s score changes tend to reflect their risk analysis, which is based on several factors that may not always align with real-world use-case scenarios. Depending on how you use your system, or what configuration changes are applied to it, the threat of a given vulnerability may be affected, changing its profile from what the original vendor assigned. As long as you always “color inside the lines,” that is mostly correct. But do something environment specific that wasn’t considered in the initial score assessment, and the risk analysis that lowered the score no longer reflects the real risk associated with not patching that vulnerability.

The Singular Vulnerability that Spells Disaster

Consider this analogy: if you had a bowl of 100 chocolates and knew that one could make you very ill, would you still take one? Just one unpatched vulnerability can compromise all security measures in place. Operating with numerous unpatched vulnerabilities across an entire server fleet is a high-risk strategy and a perfect recipe for disaster.

TuxCare Extended Lifecycle Support: A Solution

TuxCare offers backported patches from upstream projects, ensuring more comprehensive and timely fixes than official vendors. When CVEs scored high or critical by NIST are not patched upstream, the TuxCare team builds those patches and provides them to our ELS subscriber repos. Users of systems like CentOS 7 might be surprised by the number of updates available upon subscribing to TuxCare’s ELS.  For example, subscribers to our CentOS 6 ELS service have well over 300 patches that were never provided by the upstream vendor. For CentOS 7, we can provide those patches before the EOL date as well.

The post No Patches, No Security appeared first on TuxCare.

*** This is a Security Bloggers Network syndicated blog from TuxCare authored by Joao Correia. Read the original post at: https://tuxcare.com/blog/no-patches-no-security/