Compiling Openssl 3.0.8 on Rocky Linux 9

kordoz · February 17, 2023, 1:40pm

Hello!

I have successfully compiled OpenSSL 3.0.8 from source downloaded from openssl.org

fully updated OS:

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

dnf install zlib-devel make gcc perl

wget package, unpack and cd to that directory

./config --prefix=/usr
–openssldir=/etc/ssl
–libdir=lib
shared
zlib-dynamic

make

sed -i ‘/INSTALL_LIBS/s/libcrypto.a libssl.a//’ Makefile
make MANSUFFIX=ssl install

mv -v /usr/share/doc/openssl /usr/share/doc/openssl-3.0.8

cp -vfr doc/* /usr/share/doc/openssl-3.0.8

ldconfig

openssl works:

openssl version
OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023)

changed cipher of ssl.conf:

vi /etc/httpd/conf.d/ssl.conf

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

apache works

but yum and dnf are dead:

yum
Traceback (most recent call last):
File “/usr/bin/yum”, line 61, in
from dnf.cli import main
File “/usr/lib/python3.9/site-packages/dnf/init.py”, line 30, in
import dnf.base
File “/usr/lib/python3.9/site-packages/dnf/base.py”, line 29, in
import libdnf.transaction
File “/usr/lib64/python3.9/site-packages/libdnf/init.py”, line 12, in
from . import conf
File “/usr/lib64/python3.9/site-packages/libdnf/conf.py”, line 13, in
from . import _conf
ImportError: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0

The problem is incompatible library libldap.so.2 (version OPENSSL 3.0.0) ? Where obtain newer one for OPENSSL 3.0.8?

please help!

jlehtone · February 17, 2023, 2:00pm

The openssl is an integral core package. One does not mess with them. Ever!

skip77 · February 17, 2023, 3:59pm

Hello! I’ll try to expand on @jlehtone 's answer a bit, because this is an odd concept for folks outside the Linux package world.

The Rocky packages on your system are all dynamically linked against each other - many things depend on that openssl-3.0.1 version. Changing its binary API by manually upgrading (or downgrading) it is going to break all kinds of things. Many core packages like DNF, RPM, systemd, etc. were compiled against openssl-3.0.1, and expect a compatible version to be there.

In the short term, you’ll need to recover your system. I bet you’ll find there’s much more than dnf that is not working with the incompatible openssl. I recommend booting into a live/recovery disk, mounting your partition, and copying the openssl libraries from a known working Rocky 9 system. You can get the list of relevant files from the known good system with rpm -ql openssl-libs . Don’t forget to copy over the /usr/bin/openssl binary program as well(!)

In the longer term, we can look at it from a bigger picture perspective: What are you trying to accomplish? My experience with these situations usually mean it’s 1 of 2 things:

“Better security / outdated core library”: The regular default updates should take care of any security issues. Security fixes and bugfixes are backported into the older compatible version regularly, see https://access.redhat.com/security/updates/backporting for more information
“I need to run an app that requires this new version”: In this case, I’d recommend compiling the new version, but not installing it (and wrecking the system). Instead, collect the new library files into a local folder somewhere, and use export LD_LIBRARY_PATH environment variable to make your app use that folder for libraries. Alternately, look into docker/podman and possibly running your app in an isolated container.

This subject goes a whole lot deeper, but I tried to scratch the surface with this post. Hopefully it leads you to better understanding.

Thanks!

-Skip

kordoz · February 20, 2023, 8:37am

Hello! Thanks for Your answer!

I simply can not believe that Redhat 9 (and alson Rocky 9) has only openssl3.0.1 available in the repositories, which is more than one year old! I need to secure my web server and this old version has several security issues:

obrázok

So tha is why I tried to compile newer OpenSSL 3.0.8 and did not know it is incompatible with Rocky 9.

I’m gonna thinking what to do now, If recover the system from the media, or reinstall

In Rocky Linux 8 I have succesfully installed OpenSSL 3.0.8 via Raven Repo:

cat /etc/rocky-release
Rocky Linux release 8.7 (Green Obsidian)

openssl3 version
OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023)

everythng works there and it is compatible

so now I’m confused, that newer Rocky 9 is not as safe as Rocky 8 is

thanks

nazunalika · February 20, 2023, 8:59am

You have to understand that red hat does backporting. That does not mean that Rocky Linux 9 is somehow “less safe”. Rebasing on newer openssl’s can be problematic. For example, when they were developing RHEL 9 and upgraded to openssl 3, they went through and rebuilt everything.

jlehtone · February 20, 2023, 9:04am

RHEL 9 does not have “openssl 3.0.1”. RHEL 9 has a maintained and secure version of openssl 3.
See the link about backporting in post by @skip77 (and also What is backporting and how does it affect Red Hat Enterprise Linux (RHEL)? - Red Hat Customer Portal )

The RHEL 8 has openssl based on 1.1.1. You have succeeded in installing openssl 3 on the side on Rocky 8.
Since you did not replace the system openssl of Rocky 8, you did not break that system so clearly.
Do you trust that the “Raven Repo” maintains their openssl package as diligently as Red Hat maintains theirs?

iwalker · February 20, 2023, 9:08am

Also on Rocky 8, since it was OpenSSL 1.1.1 it wasn’t vulnerable to what appeared in OpenSSL 3 so it wasn’t needed to be installed.

In RHEL/Rocky 9, OpenSSL 3.0.1 has backported fixes, which means whatever was fixed in OpenSSL 3.0.5 or higher, has been applied to OpenSSL 3.0.1. Don’t go by version number alone and assuming that it is insecure. You only need to worry about that on systems that don’t backport, or when they are no longer receiving updates eg: when they go EOL. Even some security scanners go by version number without checking deeper, which then causes a false positive.

kordoz · February 20, 2023, 9:23am

Iwalker: I have another Rocky 8 , just updated, there is only old 1.1.1.k version availbable:

openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021

just made penetration test with https://pentest-tools.com/ , so here are the security issues:

If pentest tools is working right, my server is not very safe, what do you think?

kordoz · February 20, 2023, 9:24am

sorry I could not upload more, so next issue:

kordoz · February 20, 2023, 9:25am

and finally, third security issue:

jlehtone · February 20, 2023, 9:47am

On AlmaLinux 8:

# dnf -q list openssl
Installed Packages
openssl.x86_64                 1:1.1.1k-7.el8_6                  @baseos

# rpm -q --changelog openssl | grep -6 CVE-2022
* Tue Jul 05 2022 Clemens Lang <cllang@redhat.com> - 1:1.1.1k-7
- Fix CVE-2022-2097: AES OCB fails to encrypt some bytes on 32-bit x86
  Resolves: CVE-2022-2097
- Update expired certificates used in the testsuite
  Resolves: rhbz#2100554
- Fix CVE-2022-1292: openssl: c_rehash script allows command injection
  Resolves: rhbz#2090371
- Fix CVE-2022-2068: the c_rehash script allows command injection
  Resolves: rhbz#2098278

* Wed Mar 23 2022 Clemens Lang <cllang@redhat.com> - 1:1.1.1k-6
- Fixes CVE-2022-0778 openssl: Infinite loop in BN_mod_sqrt() reachable when parsing certificates
- Resolves: rhbz#2067145

* Tue Nov 16 2021 Sahana Prasad <sahana@redhat.com> - 1:1.1.1k-5
- Fixes CVE-2021-3712 openssl: Read buffer overruns processing ASN.1 strings
- Resolves: rhbz#2005402

# openssl version
OpenSSL 1.1.1k  FIPS 25 Mar 2021

AlmaLinux has built that package in August 2022. It contains Red Hat backports from July 2022. It is not “Mar 2021” any more. When did Rocky build the most recent openssl.el8 and what is in its changelog?

Both CVE-2022-1292 and CVE-2022-2068 are listed Fixed.
The el8 was Not Affected by CVE-2021-3711 according to Red Hat: Red Hat Customer Portal - Access to 24x7 support and knowledge

You pen-test produces false positives.

kordoz · February 20, 2023, 10:07am

Ok thank You very much for explanation, I really did not know that PentTest Tools is not doing real test, may be just because of they just look at the version, not doing real penetration test.

iwalker · February 20, 2023, 12:18pm

And this is what I wrote about security scanners. Unless for example, you use something like Nessus that can connect over SSH to your server to actually verify everything, then the security scan is pretty much worthless if you believe what it says without doing due diligence. In other cases such as your pentest, it requires you to manually check and verify yourself - using the dnf commands to check the appropriate package and filter for the CVE in question to see if it appears (fixed), or not.

Nessus will at least say if it was unable to check/verify whether it was affected or not (eg when not allowing access via SSH), and mentions in the scan itself about this. Thus meaning manual checks on your side to ensure it is OK.

kordoz · February 20, 2023, 12:21pm

Please, and what about security updates of httpd (apache) ? Can I also use something like
rpm -q --changelog httpd | grep -6 CVE-2022 ?

jlehtone · February 20, 2023, 12:34pm

Yes. The ‘rpm’ does query – i.e. display – the changelog (‘-q --changelog’) of installed package ‘httpd’.
One can also read changelog of package that is in repo, but not installed:
dnf repoquery --changelog httpd

The changelog can be long. If one wants to browse it, then piping to ‘less’ is convenient.
Since we are interested in specific terms, like “CVE-2022-1292”, it is more efficient to filter with ‘grep’.
However, showing only lines that do contain the regular expression loses context.
The grep option ‘-6’ (same as ‘-C 6’) shows 6 lines of output context – 6 lines before and after each matching ilne.

kordoz · February 20, 2023, 1:05pm

httpd -v
Server version: Apache/2.4.55 (Red Hat Enterprise Linux)
Server built: Jan 26 2023 17:59:25

not showing that much, nothing in 2022/23 years?

rpm -q --changelog httpd | grep CVE

Address CVE-2017-9798 by applying patch from upstream (#1490344)
Resolves: #1401530 - CVE-2016-8740 httpd: Incomplete handling of
add security fix for CVE-2016-5387
core: fix bypassing of mod_headers rules via chunked requests (CVE-2013-5704)
mod_cache: fix NULL pointer dereference on empty Content-Type (CVE-2014-3581)
mod_proxy_fcgi: fix a potential crash with long headers (CVE-2014-3583)
in multiple Require directives with different arguments (CVE-2014-8109)

jlehtone · February 20, 2023, 1:21pm

The el8 has nominally httpd-2.4.37 – latest changelog entry Jul 2022.
The el9 has nominally httpd-2.4.53 – latest changelog entry Jul 2022.
They do have several CVE-2022-*.

Your “2.4.55” is not from Red Hat/Rocky, is it?

iwalker · February 20, 2023, 3:52pm

Hmm yeah, if that version of Apache is from a third-party repository or some other source, then that will explain the problems with it being outdated and/or not being maintained frequently enough by whoever does it - far less than the httpd that is available by default in RHEL/Rocky when backported fixes are applied.

Better to not attempt replacing things using packages from other sources - stick with what RHEL/Rocky does by default when backported fixes are applied. Or assuming if this is “I need the latest and greates packages”, then you need to be looking at a bleeding edge distro like Fedora or something which has hundreds of updates from one day to the next.

kordoz · February 21, 2023, 9:50am

my fault, reinstalled:

httpd -v
Server version: Apache/2.4.37 (rocky)
Server built: Nov 8 2022 11:30:54

rpm -q --changelog httpd | grep CVE-2022

Resolves: #2097015 - CVE-2022-28614 httpd:2.4/httpd: out-of-bounds read via
Resolves: #2097031 - CVE-2022-28615 httpd:2.4/httpd: out-of-bounds read in
Resolves: #2097458 - CVE-2022-30522 httpd:2.4/httpd: mod_sed: DoS
Resolves: #2097480 - CVE-2022-30556 httpd:2.4/httpd: mod_lua: Information
Resolves: #2098247 - CVE-2022-31813 httpd:2.4/httpd: mod_proxy:
Resolves: #2097451 - CVE-2022-29404 httpd:2.4/httpd: mod_lua: DoS in
Resolves: #2096997 - CVE-2022-26377 httpd:2.4/httpd: mod_proxy_ajp: Possible
Resolves: #2065237 - CVE-2022-22719 httpd:2.4/httpd: mod_lua: Use of
Resolves: #2065267 - CVE-2022-22721 httpd:2.4/httpd: core: Possible buffer
Resolves: #2065324 - CVE-2022-23943 httpd:2.4/httpd: mod_sed: Read/write
Resolves: #2065249 - CVE-2022-22720 httpd:2.4/httpd: HTTP request smuggling

many TAHNKS !!!