Public bug reported:
[Description]
On systems running a FIPS-enabled Kernel (/proc/sys/crypto/fips_enabled = 1),
OpenSSL 3.0 (on Ubuntu Noble) fails to initialize crypto algorithms within
environments that do not have the FIPS provider module installed, such as
standard container images.
When running openssl commands inside a container on a FIPS-enabled host,
the following error occurs:
# openssl s_client -connect canonical.com:443
4007C30091790000:error:12800067:DSO support routines:dlfcn_load:could not load
the shared
library:../crypto/dso/dso_dlfcn.c:118:filename(/usr/lib/x86_64-linux-gnu/ossl-modules/fips.so):
/usr/lib/x86_64-linux-gnu/ossl-modules/fips.so: cannot open shared object
file: No such file or directory
4007C30091790000:error:12800067:DSO support routines:DSO_load:could not load
the shared library:../crypto/dso/dso_lib.c:152:
4007C30091790000:error:07880025:common libcrypto
routines:provider_init:reason(524325):../crypto/provider_core.c:912:name=fips
Root Cause Analysis:
OpenSSL on Ubuntu Noble (24.04) detects the FIPS flag enabled in the host
kernel and automatically attempts to load the FIPS provider module (fips.so).
While a host system with pro enable fips-update will automatically have
the openssl-fips-module package installed, standard container images
(e.g., ubuntu:24.04) do not include this package by default.
Consequently, the container inherits the FIPS enforcement from the
kernel but lacks the userspace libraries required to support it, leading
to the crash.
[Reproducer]
Provision a VM with Ubuntu Noble (24.04).
Enable FIPS mode (ensure /proc/sys/crypto/fips_enabled is 1).
Install Docker.
Run a standard Ubuntu container and attempt to use OpenSSL:
$ docker run --rm -it ubuntu:24.04 /bin/bash
# apt update && apt install openssl -y
# openssl s_client -connect canonical.com:443
[Workaround]
The issue can be mitigated by explicitly disabling FIPS mode enforcement for
the OpenSSL application via an environment variable:
export OPENSSL_FORCE_FIPS_MODE=0
[Additional Information]
This behavior appears to be a regression or a strictness change in OpenSSL 3.0
on Noble. The same workflow on Ubuntu Jammy does not exhibit this failure,
suggesting that previous versions handled the missing FIPS module more
gracefully or did not enforce the kernel flag as strictly in userspace.
** Affects: openssl (Ubuntu)
Importance: Undecided
Status: New
** Affects: openssl (Ubuntu Noble)
Importance: Undecided
Status: New
** Description changed:
[Description]
On systems running a FIPS-enabled Kernel (/proc/sys/crypto/fips_enabled = 1),
OpenSSL 3.0 (on Ubuntu Noble) fails to initialize crypto algorithms within
environments that do not have the FIPS provider module installed, such as
standard container images.
When running openssl commands inside a container on a FIPS-enabled host,
the following error occurs:
# openssl s_client -connect canonical.com:443
4007C30091790000:error:12800067:DSO support routines:dlfcn_load:could not
load the shared
library:../crypto/dso/dso_dlfcn.c:118:filename(/usr/lib/x86_64-linux-gnu/ossl-modules/fips.so):
/usr/lib/x86_64-linux-gnu/ossl-modules/fips.so: cannot open shared object
file: No such file or directory
4007C30091790000:error:12800067:DSO support routines:DSO_load:could not load
the shared library:../crypto/dso/dso_lib.c:152:
4007C30091790000:error:07880025:common libcrypto
routines:provider_init:reason(524325):../crypto/provider_core.c:912:name=fips
Root Cause Analysis:
OpenSSL on Ubuntu Noble (24.04) detects the FIPS flag enabled in the host
kernel and automatically attempts to load the FIPS provider module (fips.so).
While a host system with pro enable fips-update will automatically have
the openssl-fips-module package installed, standard container images
(e.g., ubuntu:24.04) do not include this package by default.
Consequently, the container inherits the FIPS enforcement from the
kernel but lacks the userspace libraries required to support it, leading
to the crash.
[Reproducer]
Provision a VM with Ubuntu Noble (24.04).
Enable FIPS mode (ensure /proc/sys/crypto/fips_enabled is 1).
Install Docker.
Run a standard Ubuntu container and attempt to use OpenSSL:
$ docker run --rm -it ubuntu:24.04 /bin/bash
# apt update && apt install openssl -y
# openssl s_client -connect canonical.com:443
[Workaround]
The issue can be mitigated by explicitly disabling FIPS mode enforcement for
the OpenSSL application via an environment variable:
export OPENSSL_FORCE_FIPS_MODE=0
[Additional Information]
- This behavior appears to be a regression or a strictness change in OpenSSL
3.0 on Noble. The same workflow on Ubuntu Jammy (using OpenSSL 3.0 or 1.1.1)
does not exhibit this failure, suggesting that previous versions handled the
missing FIPS module more gracefully or did not enforce the kernel flag as
strictly in userspace.
+ This behavior appears to be a regression or a strictness change in OpenSSL
3.0 on Noble. The same workflow on Ubuntu Jammy does not exhibit this failure,
suggesting that previous versions handled the missing FIPS module more
gracefully or did not enforce the kernel flag as strictly in userspace.
** Description changed:
[Description]
On systems running a FIPS-enabled Kernel (/proc/sys/crypto/fips_enabled = 1),
OpenSSL 3.0 (on Ubuntu Noble) fails to initialize crypto algorithms within
environments that do not have the FIPS provider module installed, such as
standard container images.
When running openssl commands inside a container on a FIPS-enabled host,
the following error occurs:
# openssl s_client -connect canonical.com:443
4007C30091790000:error:12800067:DSO support routines:dlfcn_load:could not
load the shared
library:../crypto/dso/dso_dlfcn.c:118:filename(/usr/lib/x86_64-linux-gnu/ossl-modules/fips.so):
/usr/lib/x86_64-linux-gnu/ossl-modules/fips.so: cannot open shared object
file: No such file or directory
4007C30091790000:error:12800067:DSO support routines:DSO_load:could not load
the shared library:../crypto/dso/dso_lib.c:152:
4007C30091790000:error:07880025:common libcrypto
routines:provider_init:reason(524325):../crypto/provider_core.c:912:name=fips
Root Cause Analysis:
OpenSSL on Ubuntu Noble (24.04) detects the FIPS flag enabled in the host
kernel and automatically attempts to load the FIPS provider module (fips.so).
While a host system with pro enable fips-update will automatically have
the openssl-fips-module package installed, standard container images
(e.g., ubuntu:24.04) do not include this package by default.
Consequently, the container inherits the FIPS enforcement from the
kernel but lacks the userspace libraries required to support it, leading
to the crash.
[Reproducer]
Provision a VM with Ubuntu Noble (24.04).
Enable FIPS mode (ensure /proc/sys/crypto/fips_enabled is 1).
Install Docker.
Run a standard Ubuntu container and attempt to use OpenSSL:
$ docker run --rm -it ubuntu:24.04 /bin/bash
# apt update && apt install openssl -y
# openssl s_client -connect canonical.com:443
+
[Workaround]
The issue can be mitigated by explicitly disabling FIPS mode enforcement for
the OpenSSL application via an environment variable:
export OPENSSL_FORCE_FIPS_MODE=0
[Additional Information]
This behavior appears to be a regression or a strictness change in OpenSSL
3.0 on Noble. The same workflow on Ubuntu Jammy does not exhibit this failure,
suggesting that previous versions handled the missing FIPS module more
gracefully or did not enforce the kernel flag as strictly in userspace.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2141933
Title:
OpenSSL in Noble containers panics on FIPS-enabled hosts due to
missing openssl-fips-module
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2141933/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
