Re: OpenSSL 3.0.0 security concerns using dynamic providers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux