openssl: fips.so is not self-contained

When we build fips.so we do so with the “-z defs” linker option (on Linux):

https://github.com/openssl/openssl/blob/d8d4e5fb32b3f7d9af28d21ce4c1c46cc1c7614c/Configurations/shared-info.pl#L31-L41

This is supposed to ensure that all symbols are resolved. Without this the link completes successfully even though some symbols are not defined in the resulting .so file. If that happens then I think those symbols get resolved from libcrypto at load time…which obviously would means that fips.so is not self-contained.

This used to work just fine. But it no longer seems to be the case. For example the symbol _bignum_modp_1536_p is defined here:

https://github.com/openssl/openssl/blob/d8d4e5fb32b3f7d9af28d21ce4c1c46cc1c7614c/crypto/bn/bn_dh.c#L630-L632

Since this is guarded with ifndef FIPS_MODE the symbol only exists in libcrypto and not in fips.so. The symbol is referenced from bn_const.c here:

https://github.com/openssl/openssl/blob/d8d4e5fb32b3f7d9af28d21ce4c1c46cc1c7614c/crypto/bn/bn_const.c#L85-L88

This code does get included in fips.so and the reference to _bignum_modp_1536_p is not guarded with FIPS_MODE guards like it should be. This should have resulted in a link failure - but it hasn’t.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 50 (50 by maintainers)

Commits related to this issue

Configuration: Add post module building check We want an extra check that the FIPS provider module has resolved all symbols except the standard library ones. This is generalized with the addition of... — committed to levitte/openssl by levitte 4 years ago
TEST: Add a simple module loader, and test the FIPS module with it This very simple module loader is only linked with the standard C library, so cannot and should not provide any other symbol to the ... — committed to levitte/openssl by levitte 4 years ago
TEST: Add a simple module loader, and test the FIPS module with it This very simple module loader is only linked with the standard C library, so cannot and should not provide any other symbol to the ... — committed to openssl/openssl by levitte 4 years ago

Most upvoted comments

Yes, that would make the build succeed, but that isn’t the point. The FIPS must never be linked with libcrypto. However, we ended up in a situation where, despite of that, we had a successful build with unresolved libcrypto symbols. That is possible to do on Unix… but I can’t reproduce that situation.

@levitte Passing -Wl,–allow-shlib-undefined when linking the libfips.so should allow you to have undefined symbol from libcrypto without linking it.

t8m on Nov 26, 2020

I’m not sure how a dlopen() based approach is going to work.

I’m not sure how it’s not. The problem was unresolved libcrypto symbols in the FIPS module, right? If loaded without libcrypto present (and with RTLD_NOW), the load should fail, shouldn’t it?

levitte on Nov 25, 2020