Shim15.8 RPM availability for Rocky Linux 9 to fix CVE-2023-40546 CVE-2023-40547 CVE-2023-40548 CVE-2023-40549 CVE-2023-40550 CVE-2023-40551

MathF · August 13, 2024, 6:07pm

I know there was a previous thread on this topic a few months ago, however there does not seem to be any updates available right now.
Unfortunately we are currently blocked from using this OS version at this time because it contains critical vulnerabilities and there is a fix available.
What’s the timeline to get an updated package version ?

neil · August 13, 2024, 6:10pm

Rocky’s shim-15.8 was released back in April for EL8 and EL9 which addressed all of these.

This was co-incident with refreshing our signing certificate – Secure Boot Key Refresh - 2024 - Rocky Linux

MathF · August 13, 2024, 7:19pm

ok. With the latest Rocky Linux 9.4 AMI in AWS, when I run dnf upgrade there are no updated packages for shim-x64

# cat /etc/rocky-release
Rocky Linux release 9.4 (Blue Onyx)

And the currently installed packages, after a dnf upgrade

# rpm -qa | grep shim-x64
shim-x64-15.8-2.el9.x86_64

MathF · August 13, 2024, 7:22pm

In fact, I am expecting another release, like shim-x64-15.8-4.el9_4 or something around those lines

jbkt23 · August 13, 2024, 8:26pm

Is the updated package. It was released in April and addressed those CVE’s

nazunalika · August 13, 2024, 9:13pm

shim-x64-15.8-2 is the correct version for our distribution. This not only addresses vulnerabilities, but it also introduces secure boot on ARM, which our upstream (as far as I know) does not have at this time.

Is this coming from a vulnerability scanner of some sort? If so, please work with their customer support to report it as a false positive. We also encourage companies who design said software to reach out and work with us on issues like these.

Note: We had a bug report opened up about this before. The reasoning for the difference is also explained there.

yavor-atanasov · August 28, 2024, 8:05am

Is this coming from a vulnerability scanner of some sort? If so, please work with their customer support to report it as a false positive. We also encourage companies who design said software to reach out and work with us on issues like these.

@nazunalika we are hitting an issue with this as well. We have our own scanner which uses OVAL data published by Red Hat, which we adjust to work with rocky packages. It works well, apart from this case where Rocky and RHEL have drifted in terms of patched package versions.

We did try to migrate to the Rocky OVAL data, however we hit 2 basic bugs with it, which make it unusable. I have raised 2 issues with PRs 3 months ago, but have heard nothing:

github.com/rocky-linux/oval

Rocky linux 8/9 oval data contains invalid filepath in the rpmverifyfile_object used to check if the system is Rocky Linux

opened 11:10AM - 31 May 24 UTC

yavor-atanasov

priority: medium tag: help wanted type: bug type: maintenance

Using latest Rocky Linux 8/9 oval data from https://download.rockylinux.org/pub/…oval We have an in-house tool which uses Red Hat's oval data (e.g. https://access.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2) to scan our systems for vulnerabilities. We'd like to move to Rocky's oval data. When attempting a scan with Rocky's ovals we get an error at the `rpmverifyfile_test` which tests that "Rocky Linux must be installed". The test is meant to check whether the system has the following filepath: `/etc/rocky-release`. However the filepath attribute of `rpmverifyfile_object` for this test is empty. Here are the relevant snippets from the rocky 8 oval (the rocky 9 is the same): The `rpmverifyfile_test` definition, which points to the problematic object with ref `oval:org.rockylinux.rlsa:obj:20234378001`: ``` <red-def:rpmverifyfile_test check="none satisfy" comment="Rocky Linux must be installed" id="oval:org.rockylinux.rlsa:tst:20234378001" version="1"> <red-def:object object_ref="oval:org.rockylinux.rlsa:obj:20234378001"/> <red-def:state state_ref="oval:org.rockylinux.rlsa:ste:20234378001"/> </red-def:rpmverifyfile_test> ``` And this is the `rpmverifyfile_state` definition, which basically checks that the filepath should match the expected pattern: ``` <red-def:rpmverifyfile_state id="oval:org.rockylinux.rlsa:ste:20234378001" version="1"> <red-def:name operation="pattern match">^rocky-release</red-def:name> </red-def:rpmverifyfile_state> ``` And finally the problematic object: ``` <red-def:rpmverifyfile_object id="oval:org.rockylinux.rlsa:obj:20234378001" version="1"> <red-def:behaviors noconfigfiles="true" noghostfiles="true" nogroup="true" nolinkto="true" nomd5="true" nomode="true" nomtime="true" nordev="true" nosize="true" nouser="true"/> <red-def:name operation="pattern match"/> <red-def:epoch operation="pattern match"/> <red-def:version operation="pattern match"/> <red-def:release operation="pattern match"/> <red-def:arch operation="pattern match"/> <red-def:filepath operation="pattern match"/> </red-def:rpmverifyfile_object> ``` As you can see, the `<red-def:filepath/>` tag is empty and it should contain `/etc/rocky-release`. For example this is what the Red Hat equivalent oval contains for this same object: ``` <red-def:filepath>/etc/redhat-release</red-def:filepath> ```

github.com/rocky-linux/oval

Oval data contains invalid `test_ref` which points nowhere

opened 08:42AM - 02 Jun 24 UTC

yavor-atanasov

Both the el8 and el9 ovals contain one invalid `test_ref` which points nowhere f…or defintion id `oval:org.rockylinux.rlsa:def:20233661` (title `RLSA-2023:3661: texlive security update (Important)`). The **el9** oval data contains this invalid test for that definition: ``` <criteria operator="OR"> <criterion comment="Rocky Linux 8 must be installed" test_ref="oval:org.rockylinux.rlsa:tst:unk"/> </criteria> ``` Reciprocally, the **el8** data contains this invalid: ``` <criteria operator="OR"> <criterion comment="Rocky Linux 9 must be installed" test_ref="oval:org.rockylinux.rlsa:tst:unk"/> </criteria> ``` The Red Hat ovals do not contain such a criteria for the same definition. This is the area of the code where that invalid `unk` test reference is being injected: https://github.com/rocky-linux/oval/blob/8f63e83a70224f040c5a8c25c2803ff19b02c91e/oval/transform.py#L425-L429 I've not looked into that code in great detail, but it looks like instead of injecting an invalid test, the criteria should be skipped altogether.