How to check if an RHEL system is vulnerable to a CVE

Most companies scan infrastructure devices for vulnerability every quarter, but the duration may vary depending on the company’s ITSM policy.

After the security scan, if the security team finds vulnerabilities in a specific support group, such as Linux, Windows, Middleware or Network, it will be sent to them.

Once assigned, the team will create a CR (Change Request) based on the environment such as TEST, DEV, UAT or PROD and mitigate it to make their systems more secure.

What’s CVE?

CVE stands for (Common Vulnerabilities and Exposure) is a dictionary of publicly known information security vulnerabilities and exposures.

It’s a list of records, each containing an identification number, description, and at least one public reference for publicly known cybersecurity vulnerabilities.

1) How do I check if a RHEL system is vulnerable to a specific CVE?

There are two ways you can verify that a package is patched for a specific CVE. If you know the CVE number, you can verify that the CVE is fixed on your RHEL system.

It can be done by checking the CVE number against a specific package, because each rpm package stores information about patches including date, description and CVE number.

Syntax:

rpm -q --changelog [package-name] | grep [CVE-NUMBER]

For example, to find out if ‘CVE-2021-3450’ has been applied to openssl package or not, run:

rpm -q --changelog openssl | grep CVE-2021-3450

- CVE-2021-3450 openssl: CA certificate check

Make a note: If you don’t find the CVE in the output, your system is vulnerable and you need to update the openssl package to mitigate this vulnerability.

yum update openssl

List all applied patches for openssl, run:

rpm -q --changelog openssl | grep CVE

- CVE-2021-3450 openssl: CA certificate check
- Fix CVE-2021-3449 NULL pointer deref in signature_algorithms processing
- Fix CVE-2020-1971 ediparty null pointer dereference
- fix CVE-2019-1547 - side-channel weak encryption vulnerability
- fix CVE-2019-1563 - padding oracle in CMS API
- fix CVE-2019-1549 - ensure fork safety of the DRBG
- fix CVE-2015-0209 - potential use after free in d2i_ECPrivateKey()
- fix CVE-2015-0286 - improper handling of ASN.1 boolean comparison
- fix CVE-2015-0287 - ASN.1 structure reuse decoding memory corruption
- fix CVE-2015-0289 - NULL dereference decoding invalid PKCS#7 data
- fix CVE-2015-0293 - triggerable assert in SSLv2 server
- fix CVE-2014-0224 fix that broke EAP-FAST session resumption support
- pull in upstream patch for CVE-2014-0160
- fix CVE-2013-4353 - Invalid TLS handshake crash
- fix CVE-2013-6450 - possible MiTM attack on DTLS1
- fix CVE-2013-6449 - crash when version in SSL structure is incorrect
- new upstream version fixing CVE-2012-2110
- new upstream release fixing CVE-2012-0050 - DoS regression in
- new upstream release fixing multiple CVEs
- new upstream release fixing CVE-2011-3207 (#736088)
- new upstream release fixing CVE-2011-0014 (OCSP stapling vulnerability)
- new upstream version fixing CVE-2010-4180
- new upstream version fixing CVE-2010-3864 (#649304)
- new upstream patch release, fixes CVE-2010-0742 (#598738)
  and CVE-2010-1633 (#598732)
- fix CVE-2009-4355 - leak in applications incorrectly calling
- fix CVE-2009-3555 - note that the fix is bypassed if SSL_OP_ALL is used
- fix CVE-2009-1377 CVE-2009-1378 CVE-2009-1379
- fix CVE-2008-0891 - server name extension crash (#448492)
- fix CVE-2008-1672 - server key exchange message omit crash (#448495)
- fix CVE-2007-5135 - off-by-one in SSL_get_shared_ciphers (#309801)
- fix CVE-2007-4995 - out of order DTLS fragments buffer overflow (#321191)
- CVE-2007-3108 - fix side channel attack on private keys (#250577)
- CVE-2006-2940 fix was incorrect (#208744)
- fix CVE-2006-2937 - mishandled error on ASN.1 parsing (#207276)
- fix CVE-2006-2940 - parasitic public keys DoS (#207274)
- fix CVE-2006-3738 - buffer overflow in SSL_get_shared_ciphers (#206940)
- fix CVE-2006-4343 - sslv2 client DoS (#206940)
- fix CVE-2006-4339 - prevent attack on PKCS#1 v1.5 signatures (#205180)

To check a list of applied patches in 2021 for openssl, run:

rpm -q --changelog openssl | grep CVE-2021

- CVE-2021-3450 openssl: CA certificate check
- Fix CVE-2021-3449 NULL pointer deref in signature_algorithms processing

2) Check whether a RHEL/CentOS 6/7/8 system is vulnerable or not to a CVE using yum command

Check if your system is affected by a CVE using yum command. To do so, simply install the ‘yum-security’ plugin:

For ‘RHEL 7 & 8’ systems: The plugin is already a part of yum itself so, no need to install it.

For ‘RHEL 6’, run the below command:

yum install yum-plugin-security

Check if the system is vulnerable to the CVE or has already been mitigated. For example, to find out if ‘CVE-2021-3445’ has been applied to yum package or not, run:

yum updateinfo info --cve CVE-2021-3445

Updating Subscription Management repositories.
Last metadata expiration check: 0:32:29 ago on Wed 17 Nov 2021 05:45:05 PM IST.
===============================================================================
  Moderate: dnf security and bug fix update
===============================================================================
  Update ID: RHSA-2021:4464
       Type: security
    Updated: 2021-11-09 18:46:40
       Bugs: 1804234 - yum false positive advisory if module enabled
           : 1818118 - openvswitch: yum update using wrapper file to allow for stream change fails in RHEL-8
           : 1847035 - [modularity] modulefailsafe .yaml file is not removed after module disable/reset
           : 1893176 - dnf aborts when running update
           : 1898293 - repomanage --old does not list the oldest package per module
           : 1904490 - Backtrace when performing "yum module remove --all perl:common"
           : 1906970 - dnf history wrong output if piped through more or redirected to file
           : 1913962 - "dnf needs-restarting -r" work incorrectly inside systemd-nspawn containers
           : 1914827 - [RHEL8] dnf reposync implicitly downloads source rpms in spite of no --source option
           : 1918475 - dnf --security pulling in packages without security advisory
           : 1926261 - dnf should not allow an installonly_limit less than 2
           : 1926771 - dnf does not recognize scratch modules NSVC
           : 1929163 - problem with transaction() hook
           : 1929667 - Typos in dnf API documentation
           : 1932079 - CVE-2021-3445 libdnf: Signature verification bypass via signature placed in the main RPM header
           : 1934499 - dnf autoremove wants to remove "kernel-modules-extra" if you have a rawhide kernel installed
           : 1940345 - ip_resolve, timeout, username, password options are ignored for downloading remote "rpm"
           : 1951409 - Rebase libdnf to >= 0.55.2
           : 1951411 - Rebase dnf to >= 4.5.2
           : 1951414 - Rebase dnf-plugins-core to >= 4.0.21
           : 1957280 - DNF with versionlock silences a conflict due to a provide
           : 1961632 - [dnf] RHEL 8.5 Tier 0 Localization
           : 1961633 - [dnf-plugins-core] RHEL 8.5 Tier 0 Localization
           : 1961634 - [libdnf] RHEL 8.5 Tier 0 Localization
           : 1967454 - Backport improvements of dnf signature checking using rpmkeys
       CVEs: CVE-2021-3445
Description: dnf is a package manager that allows users to manage packages on their systems. It supports RPMs, modules and comps groups & environments.
           : 
           : Security Fix(es):
           : 
           : * libdnf: Signature verification bypass via signature placed in the main RPM header (CVE-2021-3445)
           : 
           : For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
           : 
           : Additional Changes:
           : 
           : For detailed information on changes in this release, see the Red Hat Enterprise Linux 8.5 Release Notes linked from the References section.
   Severity: Moderate

Make a note: If nothing is shown in the output, the system has already been mitigated to a given CVE. But if it shows output, your system is vulnerable and you need to update the yum package to mitigate this vulnerability.

yum update yum

All CVEs are available on the Red Hat CVE Database page, and you can view the specific CVE at any time for more information:

Closing Notes

In this guide, we’ve shown you how to check if a RHEL/CentOS 6/7/8 system is vulnerable to a CVE. Also, we’ve shown you how to mitigate them if it’s vulnerable.

If you have any questions or feedback, feel free to comment below.

About Magesh Maruthamuthu

Love to play with all Linux distribution

View all posts by Magesh Maruthamuthu

2 Comments on “How to check if an RHEL system is vulnerable to a CVE”

Leave a Reply

Your email address will not be published. Required fields are marked *