OpenSSL 3.0.0 security concerns using dynamic providers

[Tomas Mraz]

On Tue, 2020-09-01 at 18:13 +0200, Tomas Mraz wrote:
> 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.

But yeah, I only now realized you are talking here about FIPS provider
and that cannot be built-in because of the need for the checksum.

-- 
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.]