OpenSSL 3.0.0 security concerns using dynamic providers

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL 3.0.0 security concerns using dynamic providers

CODERE Carl-Eric

Greetings,

                   We are currently investigating the usage of OpenSSL 3.0.0 on our side, especially for FIPS usage, but it seems that for OpenSSL 3.0.0 the providers, especially the FIPS provider, will be loaded dynamically, my main worry is that this will easily permit some kind of attacks on the cryptographic layer, for example:

 

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?

2. Having the provider entry points made public because they are dynamic will easily permit MITM attack or modification such as through hooking, have you thought of protection mechanisms to protect against this kind of attack?

 

With FIPS 2.0, from my understanding, it was statically linked, hence these risks would be lessened. Of course it required more work as it required a special linker script to add the hash value and with new NIST requirements, the FIPS mode needed to be enabled by default at premain, but my feeling as that it was more secure.

 

Thanks for your guidance!

Carl Eric Codere

 

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0.0 security concerns using dynamic providers

Matt Caswell-2


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.

I supposed you could argue that the attack surface is marginally larger
because there are more places in the filesystem that you could attack.
But with any modern operating system you are going to have multiple
places in the filesystem that would be a security issue if they allowed
malicious users to make changes.

You also have to ensure that you protect against malicious changes to
your "OPENSSL_MODULES" environment variable - which can be used to
override the default location to pick up provider shared objects. But
again this is no different to making sure a malicious user can't make
arbitrary changes to your "PATH". If they can change your "PATH" then
this means they can cause you to pick up a malicious application binary.

> 2. Having the provider entry points made public because they are dynamic
> will easily permit MITM attack or modification such as through hooking,
> have you thought of protection mechanisms to protect against this kind
> of attack?

This is much the same argument as above. You are worried about a
malicious users being able to insert malicious providers into the
system. If they can do that then they don't need to do a MITM attack.
They can just replace the FIPS provider entirely with their own version.
Again this is a serious security problem - but is no greater with
dynamic linking vs static linking.

Ultimately static linking is not designed as a security mechanism. It
seems incorrect to me to rely on it as a security control.

Matt

Reply | Threaded
Open this post in threaded view
|

RE: OpenSSL 3.0.0 security concerns using dynamic providers

CODERE Carl-Eric
> -----Original Message-----
> From: Matt Caswell [mailto:[hidden email]]
> Sent: mardi 1 septembre 2020 18:57
> To: CODERE Carl-Eric <[hidden email]>; openssl-
> [hidden email]
> 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.

> I supposed you could argue that the attack surface is marginally larger
> because there are more places in the filesystem that you could attack.
> But with any modern operating system you are going to have multiple places
> in the filesystem that would be a security issue if they allowed malicious
> users to make changes.

Actually in the case of some application, that is the assumption, that the
system is partially broken.
>
> You also have to ensure that you protect against malicious changes to your
> "OPENSSL_MODULES" environment variable - which can be used to override
> the default location to pick up provider shared objects. But again this is no
> different to making sure a malicious user can't make arbitrary changes to
> your "PATH". If they can change your "PATH" then this means they can cause
> you to pick up a malicious application binary.

Yes, sorry that context was not clearly defined, the attack scenarios that I was
discussing are based on a sandbox based system such as mobile such as iOS and Android
and partially UWP. Usually these platforms have restrictions on some of the
environment variables usage.

>
> > 2. Having the provider entry points made public because they are
> > dynamic will easily permit MITM attack or modification such as through
> > hooking, have you thought of protection mechanisms to protect against
> > this kind of attack?
>
> This is much the same argument as above. You are worried about a malicious
> users being able to insert malicious providers into the system. If they can do
> that then they don't need to do a MITM attack.
> They can just replace the FIPS provider entirely with their own version.
> Again this is a serious security problem - but is no greater with dynamic
> linking vs static linking.
>
> Ultimately static linking is not designed as a security mechanism. It seems
> incorrect to me to rely on it as a security control.
> Matt
I hope :) I have convinced you of the difference between static and dynamic
linking in certain specific contexts.

p.s: This email was sent through Outlook, so hopefully it will not be messed up too much
with line breaks when it reaches you, sorry about this.

Carl
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0.0 security concerns using dynamic providers

Tomas Mraz-2
On Tue, 2020-09-01 at 15:46 +0000, CODERE Carl-Eric wrote:

> > -----Original Message-----
> > From: Matt Caswell [mailto:[hidden email]]
> > Sent: mardi 1 septembre 2020 18:57
> > To: CODERE Carl-Eric <[hidden email]>; openssl-
> > [hidden email]
> > 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.]


Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0.0 security concerns using dynamic providers

Matt Caswell-2
In reply to this post by CODERE Carl-Eric


On 01/09/2020 16:46, CODERE Carl-Eric wrote:
> 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.

Slowing down an attack on an already compromised system is simply not a
design goal for OpenSSL 3.0. Nor was it for the FIPS Object Module 2.0
AFAIK although it might have been an accidental by-product. Once your
system is compromised there are so many ways to attack it that I
severely doubt whether the difference between static vs dynamic linking
is going to make much difference to the overall result.

But ultimately you know your application context better than I do. From
an OpenSSL perspective the decision to use dynamic linking for the FIPS
provider was fundamental and meant that we could avoid a whole heap of
problems that plagued the FOM 2.0. This isn't a design decision that is
likely to be reversed - and certainly could not be in the 3.0 timescale.
You will have to weigh the security pros and cons of this for your context.

Matt
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0.0 security concerns using dynamic providers

Tomas Mraz-2
In reply to this post by Tomas Mraz-2
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:[hidden email]]
> > > Sent: mardi 1 septembre 2020 18:57
> > > To: CODERE Carl-Eric <[hidden email]>; openssl-
> > > [hidden email]
> > > 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.]