OpenSSL 3.0.0 security concerns using dynamic providers

[Tomas Mraz]

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.
> > 
> Greetings,
>                   Thanks for the quick reply, actually from the
> perspective of mobile 
> security, once  the platform sandbox has been compromised, it is
> much 
> 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
> different.
> The goal is to add extra complexity for the attack, not to avoid it
> completely.

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.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]