Our Linux Sys Admin made the following statement below. How do you deal with that?
A great majority (discovered vulnerabilities) of these can be immediately crossed off because of [Security Backporting Practice - Red Hat Customer Portal]
Basically, a security scanner wants to see version “1234” but RHEL uses a backported version “123-4”. It’s got all the same security patches but carries a different version number because RHEL (and pretty much everyone else in the enterprise space) backports to keep features stable.
I agree that backporting is a common practice. However, our Red Hat team has never given us that excuse and tends to apply the patches we ask them to patch. The proof would vary by product/vulnerability, but you could reference the Red Hat CVE Database. If you look up the CVE-2014-3670 vulnerability provided in the Red Hat article on backporting, you can see that the vulnerability in PHP 5.3 was addressed in RHSA-2014:1768, although 5.3 went EOL prior to the RHSA being released.
This will take some manual effort, but it can prove whether the patches have been applied. If they have, you can submit exceptions for those vulnerabilities in your console so they are no longer included in metrics and reporting.
Thank you for your input. That is good information.
Your suggestion is something I can live with. Our Linux admin is pretty good with keeping things up to date.
This is more of a manual process than we prefer, but it does help validate what the Linux team is saying. Most of the checks in InsightVM are based purely on OS/product versions, and sometimes it is a little tricky to figure out if systems are actually vulnerable without tracking some of this stuff down. Best of luck!
Hi Andy and Scott,
Backporting is indeed a common practice and one that Rapid7 is well aware of. Typically, these would only show up as false positives during unauthenticated scans (because the Scan Engine doesn’t have access the distribution-specific version from the package manager).
When credentials are configured appropriately, and the template is set to correlate reliable checks with regular checks, then the authenticated checks (which are based on RHSAs or USNs or similar distribution vendor advisories) will override the results from the remote checks that only look at the version in the banner. Note that this override happens on the Security Console, once scan results have been fully integrated.
Hope this is helpful! Scott’s suggestion to look at Red Hat’s CVE pages is a great one when trying to troubleshoot any issues related to this.
All the best,
Thank you for your response. I had always checked the “correlate reliable checks with regular checks” setting since we became a R7 client about 15 months ago.
So, I think I have to dig a bit deeper and challenge our Linux admin a bit on that subject.
Again, thank you Scott and Greg for your input.
We had similar discussions. I had to really make sure they understood that
- Vulnerabilities are often discovered before patches are available [they were thinking we were blaming them for not being resolved already when discovered].
- Just because a vulnerability is discovered doesn’t mean we expect %100 patching. We realize that in some cases stability and compatibility take precedence. IVM is just to keep visibility on these, even if we never intend to patch, we are not marking them as complete or exclusions…
I have found these 2 very interesting links in regards of the backporting issue.
It is becoming a real issue…
Explanation from Red Hat: https://access.redhat.com/solutions/57665
From Nessus community: Tenable Community
also interesting is that the false positives are being reported as solved when running an investigation. See below.
So I am thinking why can the same scan an investigation performs not be done with a regular scan? That would practically fix the backporting issue with Linux.
False positive has been resolved.
After our investigation,
Red Hat: CVE-2021-35268: Moderate: virt:av and virt-devel:av security and bug fix update (Multiple Advisories)
was no longer detected on
One of our friends posted the solution to the problem over in Rapid7 Voice:
Feature Request: InsightVM and RedHat Satellite integration.
A feature I would really like to see come into the roadmap for InsightVM/Nexpose is a direct integration with Red Hat/Red Hat Satelite. When scanning the red hat enterprise environment InsightVM will report on vulnerabilities that require remediation and advise on upgrading to the latest available version, however this will not always work because Red Hat will either backport the version or decide to not fix the said vulnerability, but because Rapid7 will look into the available packages in t this often leads to false positives and result in extensive investigations only to find out that a particular version has been backported or Red Hat will not issue a fix.
These investigations can take anything from 30 minutes to an hour and that’s only 1 vulnerability, imagine dealing with several hundred of these.
Author Note, all scans conducted are authenticated, even with this in place their are a number of false positives.
Link to the description of the integration: Tenable Integrations and Partners | Tenable®
14 January 2022 (Johannesburg)