On Tue, 2020-09-01 at 15:46 +0000, CODERE Carl-Eric wrote: > > -----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. 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.]
