Hey there!
In my environment i have several Rocky Linux 9 hosts, when it comes to vulnerability management I worked like this:
I checked the results of the scan, namely CVE that is being detected based on package version
Check up fixed package version on redhat security advisory
Check the actual version of the package on the host. If it is higher or equal I am good
I wrongly assumed that Rocky and redhat have the same package versioning and rocky simply realeased the fix with a slight delay after redhat. Recently I’ve dug deeper and I have found differeneces in versioning of the fixed packages and that confused me. I want to describe on the example.
Let’s take CVE-2023-38545 related to curl
On redhat security advisory: https://access.redhat.com/errata/RHSA-2023:6745
For RHEL 9, the cve is fixed in an update RHSA-2023:6745 and the curl version that is fixed is: curl-7.76.1-26.el9_3.2.x86_64.rpm
Fixed: v 7.76.1-26
And finally i checked rocky errata for rocky 9: RLSA-2023:5763
Fixed: v 7.76.1-23
In brief package version that fixes CVE per source:
redhat RHEL 9: v 26
pkgs org for rocky linux 9: v 28
rockylinux errata for rocky9: v 23
Obviously since I am using Rocky 9 in my environment I would use Rocky linux errata as a reference, but sometimes certain CVEs are found in redhat errata and in the same time they are not covered in rocky linux errata.
For example: CVE-2023-38408 related to openssh
In redhat advisory this cve is fixed in RHSA-2023:4412.
The fixed version for RHEL 9 is openssh-8.7p1-30.el9_2.x86_64.rpm
On the other hand at rocky linux errata this CVE is only adressed in an updated related to Rocky Linux 8 ( RLSA-2023:4419 ) but not for Rocky Linux 9
How are you verifying vulnerable packages on your rocky linux machines. How do you refer this package versions? Can I safely reference the version to redhat advisory if CVE is not adressed in rocky linux errata?
I intended to make this post more verbose however since I am fresh user I need to comply with limitations to link and images, nevertheless I hope its comprehensive.
Since Rocky is direct 1:1 with RHEL, then yes you can use the RHEL errata. Also, see this thread: Apollo, Errata, & You: a CIQ OSPO request for comment where there is ongoing work to get the Rocky errata up-to-date and maintained. At which point, once complete, you’ll be able to reference the Rocky errata.
You can also use commands like:
dnf changelog httpd | grep -i CVE
to see what CVE’s are fixed. You can be more verbose, and put a full/partial CVE number to check. Like using your openssh example for Rocky8:
Thanks! This one works as well: rpm -q openssh --changelog | grep CVE
Any idea why there are differences in fixed versions across redhat and rocky linux erratas?
As mentioned already and linked in my previous post, the existing Rocky errata is not accurate and there is work on something called Apollo to replace it. Hence, as also stated, until that work is complete you can look at RHEL errata.
The changelog for 7.76.1-31 from pkgs.org has CVE-2023-38545 in 7.76.1-28.
RHEL has “development branch” (supposedly CentOS Stream).
They create a separate branch for each point update (way before release).
They backport fixes to every branch that they do maintain.
The current ‘curl’ is clearly not 7.76.1-23.el9_2.4 or 7.76.1-26.el9_3.2 plus something; the development branch had got other stuff in before the CVE-2023-38545 patch. The el9_2 and el9_3 branches had their own version numbering.
As said, the reporting of Rocky errata is not perfect yet. It is totally plausible that it has got data from source like RHSA-2023:5763.
Since my post was quite limited beside few links and one image. I imagine you have spent some time checking each source. Thanks for the time spent I appreciate your work. Yes indeed i remember they made table for RHEL 9 twice on redhat where one of them was meant to be RHEL 9.2 EUS. That explains why rocky errata and redhat are mixed. Thank you. Still I wonder why on changelog for 7.76.1-31 from: https://rockylinux.pkgs.org/9/rockylinux-baseos-x86_64/curl-7.76.1-31.el9.x86_64.rpm.html has fix for CVE-2023-38545 in 7.76.1-28 and not v26 or v23 but yet another different number.
Lets say that the development branch had version 3.el9
The el9_2 did branch and got that: 3.el9
Development branch got a two features as 4.el9 and 5.el9
The el9_3 did branch and got the 5.el9
Development branch gets one more feature: 6.el9
CVE is found. Fix is implemented.
The el9_2 branch releases fixed version: 4.el9_2 (to replace 3.el9)
The el9_3 branch releases fixed version: 6.el9_3 (to replace 5.el9)
The fix is added to development branch too as 7.el9
More development: 8.el9 and 9.el9. This is in the history of the package that is in el9_6.
Does this make it clearer how we now see “7” and not “6” or “4”?
Yes, thank you for clarification. I reckon I get it now. So the branches named after the main (dev) containing subversions for example 9.x have independent versioning counter from the main release. In this particular scenario on pkg.org there is base Rocky Linux 9 OS (main) changelog. Whereas on rocky RLSA-2023:5763 and RHSA-2023:6745 there are versions 9_2 and 9_3 (lets ignore the possibility for redhat to misscalled RHEL9 with RHEL 9.2 EUS) and thus explains the differences in numbers.
