CVEs (Common Vulnerabilities and Exposures) are constantly being discovered and patched. When discovered, it means a new security flaw exists in either an operating system or a piece of software and should be patched as soon as possible. Fixing the vulnerabilities, of course, is up to the developers. Patching those vulnerabilities, however, is up to the admin (or user). Thing is, you might not know if you’re using a piece of software that includes one or more CVEs.
How do you uncover this information? Do you have to spend hours researching? Not really. In fact, all you need to know is the CVE you’re looking for and the piece of software it affects. With those two bits of information in hand, you can quickly discover if what’s installed on your Red Hat Enterprise Linux-based distribution contains that vulnerability.
I’m going to show you how to do just that.
SEE: 40+ open source and Linux terms you need to know (TechRepublic Premium)
What you’ll need
The only thing you’ll need to make this work is a running instance of an RHEL-based Linux distribution (such as AlmaLinux, Rocky Linux or Fedora Linux). You don’t even need a user account with sudo privileges (just a regular ol’ user).
You will need to know which CVE you’re looking for. I prefer to head over to the official home of CVE listings at mitre.org. You can do a quick package-based search to view a complete list of packages that have associated CVEs.
With that OS and CVE ready, let’s check for vulnerabilities.
How to Run a CVE Check
Here’s the deal: The CVE check is quite simple. We’re going to pipe the changelog output from the rpm command to the grep command to list any possible CVEs. The syntax of the command is:
rpm -q --changelog PACKAGE | grep CVE
Where PACKAGE is the name of the installed software to be checked, and CVE is the full name of the CVE in question. Before we do that, let’s take a look at the non-piped output of the OpenSSH package. Issue the command:
rpm -q --changelog openssh
The output should be a complete listing of the changelog for openssh (Figure A).
You could scroll through the entire listing for the CVE you’re looking for, or you could pipe it through grep and have the command do the heavy lifting. Let’s say you’re looking for CVE-2020-14145, which is described as:
In OpenSSH 7.9, due to accepting and displaying arbitrary stderr output from the server, a malicious server (or man-in-the-middle attacker) can manipulate the client output, for example, to use ANSI control codes to hide additional files being transferred.
To check against that vulnerability, the command would be:
rpm -q --changelog openssh | grep CVE-2020-14145
If you see anything in the output, it means openssh has been patched against that vulnerability (Figure B).
If you don’t see anything in the output, it means openssh has not been patched and you should upgrade immediately. As long as the developers of openssh have patched the source and it’s available in the distribution repositories, the upgrade should take care of the issue.
To upgrade the package in question, issue the command (which does require sudo privileges):
sudo dnf upgrade PACKAGE
Where PACKAGE is the software in question. Once the upgrade completes, run the CVE check again to see if the package has been patched for the vulnerability. If not, keep coming back to the upgrade, and (hopefully) the software maintainers will get that issue fixed asap.
And that’s all there is to checking for CVE vulnerabilities in the packages you have installed on your RHEL-based Linux distributions.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.
Subscribe to the Developer Insider Newsletter
From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays