The latest httpd rpm version from Rocky Linux is httpd-2.4.37-43.module+el8.5.0+747+83fae388.3.x86_64.rpm but the latest from RHEL 8 is httpd-2.4.37-43.module+el8.5.0+14530+6f259f31.3.x86_64.rpm . Is there a reason the version numbers are different? Grype for instance keeps reporting that httpd is susceptible to CVE-2022-22720 since it is expecting to see the RHEL 8 version numbers.
Thanks.
Grype output:
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
httpd 2.4.37-43.module+el8.5.0+747+83fae388.3 0:2.4.37-43.module+el8.5.0+14530+6f259f31.3 rpm CVE-2022-22720 High
I apologize that you’re running into this issue. From a Release Engineering team standpoint, this is a module build system nuance that we don’t control. That number 747 is the 747th module build that has been done over all, as of that particular module. The next module we build, regardless of what it is, will be 748. In Red Hat’s case, that’s the 14530th module build in their environment. That is a lot of modules and they clearly do a lot of builds. We would need to rebuild that package with MBS and koji numerous times to get to that number, and it’s not really reasonable to do that (never mind time consuming).
With that being said though, this is one of many issues with a lot of these vulnerability scanners. They’re either…
A) Looking at the NEVRA from Red Hat and use that as the ultimate baseline not completely aware of how modules work, and thus not taking into account how derivatives are doing it.
or…
B) Looking at the NEVRA (regardless of what distribution), ignoring how Red Hat does backports and still say a particular version is vulnerable since they only look at httpd-2.4.37 and say “yep that’s vulnerable”
With point A (which is what you and many other users are facing), this is something that a lot of these scanners haven’t been updated to understand. It’s not just us, the other derivatives will face the same issues. There’s nothing we can really do about it other than put pressure on the devs of these scanners to fix things up.
As an aside too… Not even oracle matches when their httpd package has this: httpd-2.4.37-43.0.3.module+el8.5.0+20624+5d3b49d0.3 - not only do they have a higher module version and a different ending context, they have 43.0.1, implying they’ve made other changes. I imagine there’s going to be scanners that are confused by this.
This is something that would need to be taken up with the developers of Grype and other scanners that produce these types of results.
2 Likes
Thanks for the explanation. This explains why Almalinux has a different version also. I will see if something can be done on the Grype side of things.
Thanks again.
I’ve never used Grype, that said, I have used Nessus and Nessus behaves similarly that if you just scan, without allowing the scanner to have SSH access to the server it will report that it thinks the server might have a vulnerability, rather than say it is vulnerable. When I then configure my scan in Nessus to use an SSH key and connect as a particular user to the server it will then provide more accurate results as I believe Nessus then can do more deeper checks once it connects over SSH. I find I have far less false-positives that way if it’s able to check/verify properly.
So, not sure if you can do the same with Grype or not, but it would be worth a shot.
Grype runs locally and does inspect the rpm database. The problem is it thinks the only acceptable version of httpd for RHEL8 and variants is httpd-2.4.37-43.module+el8.5.0+14530+6f259f31.3.rpm . The Rocky version is httpd-2.4.37-43.module+el8.5.0+747+83fae388.3.x86_64.rpm so it always reports httpd is vulnerable to CVE-2022-22720 even though it is not. The solution for grype would be to have Rocky specific stuff in it’s vulnerability database.