Unpatched CVE in openssl 1.1.1

[adb014]

As annonced previously openssl 1.1.1 is now unsupported. Since late octobre there are now unpatched vulnerabilities in openssl 1.1.1, these being https://www.cvedetails.com/cve/CVE-2023-5363/ and https://www.cvedetails.com/cve/CVE-2023-5678/. The first is relatively nasty as it might imply that openssl can not guarantee the confidentiality due to IV reuse. The dependencies of all packages using openssl should be updated to openssl 3.2.0.

Reading the migration guide https://www.openssl.org/docs/man3.0/man7/migration_guide.html the migration to 3.2.0 will mean that all packaging using openssl will need to be recompiled. I suppose we can do this in stages

1. Include an openssl 3.2.0 package in tinycore that can co-exist with openssl 1.1.1. Don't link /usr/local/lib/{libcrypto.so|libssl.so} to their 3.2 versions at this point.
2. Rebuild package  by package with openssl 3.2 as a dependancy. The link should be explicitly to the correct shared library
3. At some point  link /usr/local/lib/{lincrypto.so|libssl.so} to their 3.2 versions. This might cause problems to packages that link to libcrypto.so or libssl.so
4. In a year ot two remove openssl 1.1.1

I'm willing to help out with this, but I've never submitted compiled packages for tinycore before 

[Juanito]

I'll make an openssl-3.2 (or maybe 3.0) extension soon, but the rebuild of existing extensions will probably wait until 15.x

[adb014]

As long as openssl 1.1.1 and openssl 3.x can co-exist in the same distribution, there doesn't seem to be much risk to update the extensions piecemeal. Once you propose your 3.x package, I'll propose an example build of a major package (something like openssh as self contained) that could be used to show that they can co-exist.. I agree its a major effort to update all packages, which is why it probably needs to be done package by package

[gadget42]

I'll make an openssl-3.2 (or maybe 3.0) extension soon, but the rebuild of existing extensions will probably wait until 15.x

roughly how many existing extensions might that be(curiosity-always-gets-the-best-of-me)?

[Rich]

Hi gadget42
TC14 x86    has 66 .dep files that list "openssl-1.1.1.tcz".
TC14 x86_64 has 82 .dep files that list "openssl-1.1.1.tcz".

That doesn't include any -dev extensions that might be affected.

[Juanito]

..and some are masked by recursive deps, i.e. the actual number will be somewhere between the those containing openssl in the dep file and those containing openssl in the tree file.

[adb014]

I think the situation might be a little worse than just 82 + 66 packages to rebuild. If openssl if a dependency of a dependency is a rebuild needed ? For example libssh2.tcz.dep includes openssl-1.1.1. Doesn't this mean that any package that depends on libssh2 might also need to be rebuild ? It really depends on if the *.tcz.dep files always include openssl-1.1.1 if the source code of the package calls any openssl functions, or if the person who packaged the file just included a dependency that included openssl.

[Paul_123]

I think the situation might be a little worse than just 82 + 66 packages to rebuild. If openssl if a dependency of a dependency is a rebuild needed ? For example libssh2.tcz.dep includes openssl-1.1.1. Doesn't this mean that any package that depends on libssh2 might also need to be rebuild ? It really depends on if the *.tcz.dep files always include openssl-1.1.1 if the source code of the package calls any openssl functions, or if the person who packaged the file just included a dependency that included openssl.

Yes, its a lot of work, but as long as the app only used libssh2 library calls, then it should be fine.

[CNK]

If openssl if a dependency of a dependency is a rebuild needed ?

as long as the app only used libssh2 library calls, then it should be fine.

An example of where a similar assumption isn't correct is that dillo.tcz.dep on x86_64 has the following entries:

Code: [Select]

wget.tcz
libXcursor.tcz
fltk-1.3.tcz
dejavu-fonts-ttf.tcz

wget.tcz.dep contains only "ca-certificates.tcz", which depends on "openssl-1.1.1.tcz". In fact both the wget.tcz and dillo.tcz extensions contain binaries that link against the OpenSSL 1.1.1 library, so those both need to be updated (I don't know about ca-certificates.tcz), even though they wouldn't appear in a list of extensions with "openssl-1.1.1.tcz" in their dep files.

This discussion made me wonder about what Debian's doing, since Debian 10 and 11 (Buster and Bullseye) both use OpenSSL 1.1.1. Debian 10 is in Long-Term-Support which offers limited security updates, and 11 is still supposed to receive full security updates until mid next year. I found this forum discussion which explains that OpenSSL 1.1.1 is intended to still be supported there now, but nobody explains how. It links to OpenSSL in their package tracker, but it shows that the latest update to Debian's OpenSSL 1.1.1 packages was integrating the last upstream release, OpenSSL 1.1.1w. They haven't released fixes for those mentioned vulnerabilities.

Still, if someone does patch OpenSSL 1.1.1 for Debian, it would be good if the TC openssl-1.1.1.tcz extensions could be updated with those patches (which should be downloadable from the Debian packages website) until all the programs linking against OpenSSL are rebuilt for version 3.

[Juanito]

openssl(3.2) added to the x86_64 repo.

openssh, xorg-server, wpa_supplicant-dbus, python3.6 and python3.9 have been re-compiled against openssl(3.2).

opensssl-1.1.1 has been adjusted so that it only contains libraries and openssl-1.1.1-dev has been left as-is for now.

When compiling make sure openssl-dev is loaded before openssl-1.1.1-dev.

edit: recompiled wget and libssh2 also added

[Juanito]

openssl(3.2) added to the x86 repo.

curl, libssh2, openssh, xorg-server, wpa_supplicant-dbus, python3.6, python3.9 and wget have been re-compiled against openssl(3.2).

opensssl-1.1.1 has been adjusted so that it only contains libraries and openssl-1.1.1-dev has been left as-is for now.

When compiling make sure openssl-dev is loaded before openssl-1.1.1-dev.

[CNK]

Thanks for your work Juanito.

The dillo.tcz (x86_64 only), and dillo-beta.tcz extensions (probably others too - netsurf.tcz?) depend on openssl-1.1.1.tcz but only included it via ca-certificates.tcz.dep as I described in my last post. Since ca-certificates.tcz.dep has now been changed to "openssl.tcz", new installations of those web browser extensions won't work. If libevent.tcz.dep is changed to "openssl.tcz" later, that will break the links-full.tcz extensions too.

Hopefully these extensions will be rebuilt for OpenSSL 3.2, and as maintaininer of links-full.tcz for x86_64 I plan to do so for that one soon. But for now would it be a good idea to add "openssl-1.1.1.tcz" to the .dep files of those browser extensions so that new installations work in the mean time?

PS. I wrote a patch for the dillo.tcz source code that added SNI support to the included HTTPS plug-in. I'll test that with OpenSSL 3.2 soon and then perhaps the dillo.tcz maintainer (neonix) would be interested in using it if/when they rebuild the dillo.tcz extension? Many websites fail to load without SNI now.

[Juanito]

dillo and dillo-beta dep files modified

[Juanito]

Many extensions have been recompiled against openssl (3.2.0) in the x86 and x86_64 repos - thanks to @andyj

[adb014]

The package "php-7.4-ext", "php-8.0-ext", "php-8.1-ext" and "php-8.2-ext" also need to be rebuilt, as they include an openssl.so PHP module linked against openssl-1.1.1