Your app uses a defective version of the OpenSSL library, which can cause your app to crash. Update to a fixed version of OpenSSL.
Defective versions:
OpenSSL 1.1.1g in lib/x86_64/libopenvpn.so
https://support.google.com/faqs/answer/12576638
Related
I wanted to ask you something that it's happening probably since ever and I didn't notice until now.
Some days ago I upgraded openssl to the latest version (1.1.1k) in a Debian server
I recently installed a software on the server to check vulnerabilities but it's still alerting about an old openssl version.
For some reason, when I run the "openssl version" command, it shows up this information:
OpenSSL 1.1.1k 25 Mar 2021 (Library: OpenSSL 1.1.1d 10 Sep 2019)
I wonder if I did something wrong when I compiled it. This are the instructions I'm using:
./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlib-dynamic
make
make install
Have you ever had a similar problem before? Do you know how to fix it?
Thanks.
[Edited]
I have installed a brand new server with Debian 10, minimal install (network). I have downloaded and compiled zlib and openssl. Once again, if I run "/usr/local/ssl/bin/openssl version" I got the same results:
OpenSSL 1.1.1k 25 Mar 2021 (Library: OpenSSL 1.1.1d 10 Sep 2019)
[Edit2 ]
I have installed a brand new virtual server with only Debian 10, minimal no packages installed by default. I have used only openssl 1.1.1k, downloaded and still the same problem:
(Library: OpenSSL 1.1.1d 10 Sep 2019) openssl 1.1.1k
What is the output if you run:
openssl version
and
which openssl
?
Those commands together will tell you what version of openssl your operating system has in its path. I would think that the compilation of openssl either did not run succesfully or did not install openssl in the proper place.
You can see if there are other openssl binaries in your server by running:
find / -name openssl
as root. If there are, you can check their versions to see if any of them has the version you expect.
As an extra word of advice, i would recommend that you download a pre compiled package instead of compiling directly in the server (For production servers, this is in itself a security risk). Additionally, did the compilation and install completed successfully? These usually have lengthy outputs, and maybe an error was missed.
In a server linux Centos 5 64bit, I have compile from the source code the webserver Apache version 2.4.6.
Below, the configure instruction that I have used.
./configure --enable-mods-shared=reallyall --with-suexec-caller=apache --enable-cache --enable-cache-disk --with-ldap --enable-ldap --enable-authnz-ldap
Now, I must recompile the webserver Apache to using the new installed version of openssl (1.0.1e-fips).
What is the correct syntax to reconfigure Apache to using the current version of openssl installed on the server?
Many thanks at all.
As you unfortunately didn't mention how you installed OpenSSL 1.0.1e-fips (and where), this can't be answered. Based on 1.0.1e-fips, I see some chances that you used my openssl101e RPM package from EPEL 5 (even more important: openssl101e-devel). If so, run
export CFLAGS="$CFLAGS -I/usr/include/openssl101e"
export CPPFLAGS="$CPPFLAGS -I/usr/include/openssl101e"
export LDFLAGS="$LDFLAGS -L/usr/include/openssl101e"
before ./configure. Otherwise you first need to reveal more details about your OpenSSL 1.0.1e-fips installation/update.
I'm trying to develop .NET Core in openSuse. I did install the SDK and everything in tutorials. Now, when I try to run dotnet new console command, I get this error:
No usable version of the libssl was found
Aborted (core dumped)
I found this answer: (.NET Core 2.1 SDK Linux x64 No usable version of the libssl was found), but didn't get what should I do to solve problem. They seems are deep-linuxer (which I'm not, I'm just trying to learn linux). Have any idea how to run the command?
UPDATE: System info:
openSUSE Leap 15.0
Kernel Version 4.12.14-lp150.12.22-default
OS Type:64-bit
I was having the same problem running sqlpackage on Ubuntu 20.04 while dotnet was working regularly.
dotnet is distributed through apt as well as sqlserver, but for some reasons sqlpackage is instead distributed via zip here (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-ver15) and is still affected by missing libssl1.0.
Solved with
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
Can you install the libopenssl1_0_0 packages? .NET Core should pick it up and use it.
A slightly longer explanation for anyone who is curious:
OpenSSL is one of the most common cryptographic libraries used on Linux. It has multiple versions. Version 1.0 is kind of old, but heavily used. 1.1 is the newer version that was (relatively) recently released. 1.0 and 1.1 are not compatible. An application that expects 1.0 can not build against 1.1, nor run against it.
.NET Core 2.1, and all earlier versions only support OpenSSL 1.0.
Many Linux distributions are starting to make OpenSSL 1.1 the new default. But most of them still have a package for 1.0. So you just need to find and install that. On Fedora it's compat-openssl10. For openSuSE, it's libopenssl1_0_0. Then .NET Core will find it, pick it up and use it automatically.
Edit: As of March 2019, this shouldn't be required. We have updated .NET Core 2.1 and later to pick up and work with either OpenSSL 1.1 or 1.0 (whatever is available). So this problem should no longer happen with recent releases of .NET Core.
Ubuntu 22.04
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
Still get this on Fedora 30 (with compat-openssl10 installed) when using the sqlpackage tool (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-2017).
$ dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.203
Commit: e5bab63eca
Runtime Environment:
OS Name: fedora
OS Version: 30
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.2.203/
Host (useful for support):
Version: 2.2.4
Commit: f95848e524
.NET Core SDKs installed:
2.2.203 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Dotnet works fine on it's own. But running sqlpackage does not work:
$ sqlpackage /tsn:localhost /tu:xx /tp:yyy /A:Import /tdn:mydb /sf:mydb.bacpac
Importing to database 'mydb' on server 'localhost'.
No usable version of the libssl was found
Aborted (core dumped)
I looking up "No usable version of the libssl was found" in github. You'll find many variants of the .Net core security library in C, each varient has very specific dll loads for exact libssl libraries and everything has to match perfect despite it being named differently in many.
For raspberry pi / debian it wants libssl 1.0.2 exactly, nothing else.
sudo apt-get install libssl1.0.2
should do the trick for the pi! I can't speak to other variants.
I've developed an application for GNU/Linux that uses the OpenSSL library. This application is supposed to run in both Debian and Red Hat-based distributions.
What is the best strategy to ensure the user's system will have the OpenSSL library installed? Should I include a dependency on the .deb or .rpm for a specific version of the OpenSSL? How can I handle systems with older versions of OpenSSL, such as 0.9.8, and newer ones with 1.0.0? Or is it best to statically link it?
Thank you
Ubuntu uses Debian packages (.deb), RedHat uses RPM. You will have to create two different spec files to build packages for these two distributions, at least.
When you dynamically link against different versions of the library, you should really build several versions of your executable as well. Usually, the .so API is only guaranteed to stay the same for a major version. I.e. 0.9.4 will be compatible to 0.9.9, but not 1.0.1.
How do I resolved this error on Solaris 11?
"Could not autodetect OpenSSL support. Make sure OpenSSL development packages are installed. Use configure --without-ssl to disable this message."
It is odd because I know that I have openssl 1.0.0e.
Also I know that Node is looking in /usr/include and that the files /usr/include/openssl/ssl.h and /usr/include/openssl/crypto.h exist.
Ubuntu Equivalent
The "OpenSSL development packages" are actually not the "openssl" package.
You need to apt-get (or similar for Solaris) install the package called "libssl-dev".
For me, this solved the problem while trying to configure the source for node.js.
If you have openssl already installed in /usr/local/ssl, use those configure options:
--openssl-includes=/usr/local/ssl/include --openssl-libpath=/usr/local/ssl/lib