I noticed that Rocky Linux is currently using OpenSSL v1.1.1, which was the most recent GA for OpenSSL until just recently. OpenSSL has now released OpenSSL v3.0. OpenSSL v1.1.1 does not support the FIPS object module that allows you to seek a FIPS certification on the OpenSSL implementation. OpenSSL v3.0 more or less integrates that FIPS module into the OpenSSL v3.0 release. We’d really like to be able to use Rocky Linux and still seek a FIPS 140-3 certification. What are the plans, if any, to move Rocky to OpenSSL v3.0?
Remember, Rocky 8 is just a rebuild of upstream RedHat 8. So the official version of OpenSSL will always be what RedHat provides in their distro.
There may be additional repos that offer OpenSSL 3, but the core OS will always match RedHat. And since the whole point of RedHat Enterprise is to be consistent and since OpenSSL-3 has breaking compatibility changes to OpenSSL-1.1 I very very much doubt the core will change.
2 Likes
One could ask: does RHEL 8 have FIPS 140-3? If yes, how?
Good point @sweh . Rocky would move to OpenSSL 3.0 until Red Hat moves. So the real question is when will Red Hat move to v3.0. I guess I’ll go ask in a Red Hat forum. thanks!
@jlehtone - I think it’s a little more complicated than that. RHEL 8’s implementation of OpenSSL does have a FIPS 140-2 certification, but it seems all the functionality to meet the FIPS requirements is added during the Red Hat build process so the source that is shared does not provide the FIPS object module functionality. I think this is one of the things you get when you pay for Red Hat’s built product.
RHEL 8 FIPS: Cryptographic Module Validation Program | CSRC
My guess would be “not before RedHat 9”.
Does anyone have information about updating OpenSSL from default 1.1.1g to 1.1.1k or 1.1.1l? I have found website instructions, but after trying on 5-6 different VM’s, amongst myself and coworker, whenever we reboot it doesnt come back up
After following all instructions and typing ‘openssl version’, i confirm i successfully updated it to 1.1.1h or 1.1.1k, but as soon as i reboot, i come to a blank black screen with Rocky Linux on the bottom, but no username/password prompt ever appears.
You shouldn’t replace OS provided libraries with alternate ones. Firstly it may not work, but even if it did then the next time there’s an OS patch for the package it’ll overwrite what you put there. So even if you got 1.1.1k today, tomorrow you might find 1.1.1g put back.
Note that RedHat backport security patches without changing the release version. So RedHat’s 1.1.1g-15 should be fully patched. They also sometimes add functionality, if it’s not a breaking change. So looking at the changelog (rpm -q --changelog openssl) we can see:
* Thu Mar 25 2021 Sahana Prasad <sahana@redhat.com> 1.1.1g-15
- version bump
* Wed Mar 24 2021 Sahana Prasad <sahana@redhat.com> 1.1.1g-14
- CVE-2021-3450 openssl: CA certificate check
bypass with X509_V_FLAG_X509_STRICT
* Wed Mar 24 2021 Sahana Prasad <sahana@redhat.com> 1.1.1g-13
- Fix CVE-2021-3449 NULL pointer deref in signature_algorithms processing
* Fri Dec 04 2020 Sahana Prasad <sahana@redhat.com> 1.1.1g-12
- Fix CVE-2020-1971 ediparty null pointer dereference
* Mon Nov 02 2020 Tomáš Mráz<tmraz@redhat.com> 1.1.1g-11.1
- Implemented new FIPS requirements in regards to KDF and DH selftests
- Disallow certificates with explicit EC parameters
1 Like
Yes indeed: Rocky Linux 9.0 currently provides openssl version 3.0.1 from the BaseOS repo.
Will the 3.0.7 update be available soon? The upstream release is supposed to drop today, Nov. 1.
Thanks,
-jm
openssl 3.0.7 will not come to Rocky 9. 3.0.1 will be patched to version 3.0.1-43 and sent out for mirrors to sync. It is rare for Red Hat to rebase openssl to a newer release.
Both CentOS Stream 9, RHEL 9, and Rocky Linux 9 will have 3.0.1-43 that revolves the two current CVE’s.
@nazunalika Will there be an official Errata to announce the remediation of CVE-2022-3602 & CVE-2022-3786 in OpenSSL 3.0.1?
Errata is not supported in Rocky Linux 9 repositories yet from peridot (the new build system). It may come sometime during 9.1.
Until the Errata are supported by your backend build system, how should users find out which products are affected by vulnerabilities and which packages remediate the issues?
You can do what you always had todo with CentOS: run dnf up regularly. That gives you what exist.
Run rpm -q --changelog openssl and you see what you have. Sort of.
1 Like
@abunn-r7 you can do something like this:
[root@rocky9 ~]# dnf changelog openssl | grep -i cve
- CVE-2022-3602: X.509 Email Address Buffer Overflow - running tests
Resolves: CVE-2022-3602
- CVE-2022-3602: X.509 Email Address Buffer Overflow
Resolves: CVE-2022-3602
- CVE-2022-2097: AES OCB fails to encrypt some bytes on 32-bit x86
Resolves: CVE-2022-2097
- CVE-2022-2068: the c_rehash script allows command injection
gives you a list of what’s currently been addressed. So the first one you listed is on there.
1 Like
Thank you for your responses, however this does not solve the problem I am facing. This might work nicely for one or two machines running Rocky, but if I have a fleet of machines all with different packages and I need to ensure I am targeting the most severe vulnerabilities first, this approach is not useful. Not everyone can update everything all the time. Many companies have patching/maintenance windows and can only update one thing at a time to ensure compatibility between updates.
By not publishing the Errata it makes it very difficult for a user to determine whether a vulnerability affects Rocky 9 or not. It’s pretty standard for operating systems with package managers to issue advisories for their products. Rocky does this for v8. Everyone else does this for every OS they ship. I would think this is a requirement for an enterprise-ready OS.
As Louis mentioned, Errata will be coming for 9.x sometime in 9.1.
This is an open source, community supported operating system. As others have mentioned, Errata is something that never even existed for CentOS, so there are known ways to work around this. Moreover, most users won’t adopt a new OS within the first year of its release anyways, meaning there are not really ‘fleets of servers’ running 9.x yet–at least, not in the organizations I am involved with.
We understand your issue, and it is being worked on, however these things aren’t just switches we flip on and off. It requires development work & time, QA work & time, and further time and energy to maintain long term for the community. Take it from me–we don’t maintain these features for us, but because they are asked for by the community. A small amount of patience is all that is asked in return.
1 Like
Thanks @neil for the background info! This context helps to paint the bigger picture.
I truly do understand that the open-source community that drives Rocky is full of people donating their time and efforts, and that things like documentation are often the lowest effort-to-value items in any project.
If the security errata process is an area that needs attention, how can I get involved in helping out?