> -----Original Message----- > From: Matt Caswell [mailto:matt@xxxxxxxxxxx] > Sent: mardi 1 septembre 2020 18:57 > To: CODERE Carl-Eric <carl-eric.codere@xxxxxxxxxxxxxxx>; openssl- > users@xxxxxxxxxxx > 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
