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