Chapter 2. Common Vulnerabilities and Exposures (CVEs)

Red Hat Security Advisory (RHSA) errata document security vulnerabilities in Red Hat products for which there are remediations or mitigations available. The Red Hat Insights for Red Hat Enterprise Linux vulnerability service displays the advisory identifier tied to each system exposed to a CVE.

View this information by selecting a CVE and selecting the Filter by affected systems link in the security rule card. If an advisory exists for the system, the RHSA ID is visible as a link next to the system in the Exposed systems list, Advisory column. When there are no such advisories, the Advisory column is not visible, or will show “Not available.”

When an advisory exists for a system, users can view more information about the RHSA, including a list of affected systems. In the patch service, users can select systems to create an Ansible Playbook to apply the remediation.

Security rules are CVEs given additional visibility due to the elevated risk and exposure associated with them. These are security flaws that may receive significant media coverage and have been scrutinized by the Red Hat Product Security team, using the Product Security Incident Response Plan workflow to help determine your RHEL environment exposure. These security rules enable you to take the appropriate action to protect your organization.

Security rules provide deep threat intelligence, beyond analyzing the version of RHEL running on a system. Security rules are manually curated to determine whether you are susceptible to a security threat by analyzing system metadata collected by the Insights client. If the vulnerability service identifies a system as exposed to a security rule, there is the potential for elevated security risk and issues should be addressed with urgency.

Finally, not all systems exposed to a CVE are also exposed to a security rule associated with that CVE. Even though you may be running a vulnerable version of software, other environmental conditions may mitigate the threat; for example, a specific port is closed or if you are running SELinux.

Red Hat analyzes Metasploit data to determine whether code exists publicly to exploit a CVE, or a CVE has already been exploited publicly. The vulnerability service applies the “Known exploits” label to CVEs that meet that criteria.

This enhanced threat assessment can help users identify and address those CVEs that pose the most critical risks first. Red Hat recommends users review any CVEs with the “Known exploit” label with high priority and work towards remediating those issues.

The vulnerability service provides you with data about individual Common Vulnerabilities and Exposures (CVEs) and their effect on your systems registered to Insights. CVEs are categorized as vulnerable or affected but not vulnerable. This level of threat intelligence is available for CVEs that have the Security Rule label or for those that have gone through Red Hat Product Security’s rigorous analysis.

This increased threat intelligence enables you to triage issues and address the most urgent ones first. When managing a large fleet of servers, this translates into expedited protection and significant efficiencies.

An affected but not vulnerable CVE status indicates that you are running software that has a vulnerability in it but is not currently exploitable. This system will need remediation but does not require immediate attention.

A vulnerable CVE status indicates flawed code with an open path to exploitation. An open path could be a port or an OS version that permits one of the following: confidential information to be leaked, the integrity of the system to be compromised or availability of the system to be hindered.

Let us look at an example of a vulnerable server versus an affected but not vulnerable server:

Suppose that Server A is running vulnerable software that allows root access to the system. Server A would be considered vulnerable and require immediate patching.

In contrast, suppose that Server B’s current configuration prevents the vulnerability from manifesting, even when present in the affected code. Server B would be considered affected but not vulnerable. This would mean that Server B could be relegated to the to-do list, so that the more immediate threat, Server A could be remediated.