OpenSSL 3.0.0 security concerns using dynamic providers
tmraz at redhat.com
Tue Sep 1 16:13:15 UTC 2020
On Tue, 2020-09-01 at 15:46 +0000, CODERE Carl-Eric wrote:
> > -----Original Message-----
> > From: Matt Caswell [mailto:matt at openssl.org]
> > Sent: mardi 1 septembre 2020 18:57
> > To: CODERE Carl-Eric <carl-eric.codere at thalesgroup.com>; openssl-
> > users at openssl.org
> > Subject: Re: OpenSSL 3.0.0 security concerns using dynamic
> > providers
> > On 01/09/2020 03:01, CODERE Carl-Eric wrote:
> > > 1. Replacing the provider by a tampered provider by replacing the
> > > shared/dynamic library. This can partially be protected by the
> > > caller
> > > verifying the hash of the provider before calling it, will
> > > OpenSSL
> > > 3.0.0 do this, or will need to be done at integrator level?
> > The OpenSSL 3.0 FIPS module checks its own integrity when it is
> > first loaded.
> > This is really intended as a sanity check. It doesn't really
> > protect against
> > malicious changes.
> > I don't really see why you see this is a security concern. Of
> > course, yes, if a
> > malicious user was able to replace the shared/dynamic library then
> > this
> > would be a serious security problem. But why is this a greater risk
> > with
> > shared/dynamic libraries compared to static linking? In much the
> > same way if
> > a malicious user can change the application binary then you have a
> > security
> > problem.
> > In other words if a malicious user has the ability to change any
> > arbitrary
> > application executable or shared library then you have a security
> > problem.
> > The risk doesn't really change with dynamic vs static linking.
> Thanks for the quick reply, actually from the
> perspective of mobile
> security, once the platform sandbox has been compromised, it is
> easier for an attacker to replace a shared library with another one
> he has
> programmed than statically analyzing a properly stripped application
> to discover
> its cryptographic entry points and then patching it and/or hooking it
> (In the
> shared library the entry point names are clearly visible)... Hence
> final asset
> loss is the same, but the actual time to do the attack would be
> The goal is to add extra complexity for the attack, not to avoid it
You can still build and link openssl without shared library loading
support. The default provider will be then built-in. Of course, you
then won't be able to load any external providers.
No matter how far down the wrong road you've gone, turn back.
[You'll know whether the road is wrong if you carefully listen to your
More information about the openssl-users