OpenSSL 3.0.0 security concerns using dynamic providers

[Matt Caswell]

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