[openssl-users] Static FIPS Library with Address Randomization

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Neptune
> Sent: Friday, March 17, 2017 09:26
> To: openssl-users at openssl.org
> Subject: [openssl-users] Static FIPS Library with Address Randomization
> 
> Platform: Win32
> FIPS Object Module: 2.0.13
> OpenSSL: 1.0.2j
> 
> We've been using FIPS-capable OpenSSL for over a year now. Some of our
> components are .dlls that statically link the libraries. Using the BASE:xxxx
> linker flag (but not /FIXED) has worked well with only very occasional
> address clashes.
> The new year has brought a new requirement: NIAP. One of the NIAP
> requirements is ASLR - address space layout randomization. Since turning on
> these linker flags, the FIPS POST has been failing due to dll address being
> randomized and no longer respecting the requested address in the BASE:xxxxx
> linker flag. In order to get around this, I've had to add the /FIXED flag.
> The address is no longer being randomized and the POST succeeds if the dll
> loads...but therein lies the problem. When linking with the /FIXED flag, if
> the BASE:xxxx address is not available, the dll will not load which is an
> unacceptable problem and it is happening far too frequenctly.
> It seems as though the requirements of FIPS-capable OpenSSL and NIAP address
> randomization are at odds. Is there any way to satisfy both of these
> requirements on Win32 and guarantee that the dll load?

AIUI, NIAP is just the US implementation of Common Criteria; you're better off using the latter term in general discussion, I think.

I don't believe there is a solution to this problem, generally speaking, for 32-bit processes. (A 64-bit address space gives you a much better chance of finding a base address with a very low probability of conflicts.)

This is simply one of the many problems with FIPS 140-2, particularly for software implementations. Those problems have been discussed extensively on this list; you can find many others weighing in on them, such as:

https://blogs.oracle.com/darren/entry/fips_140_2_actively_harmful

For OpenSSL specifically, this specific question has also been discussed elsewhere, for example:

http://stackoverflow.com/questions/36268301/consequences-for-adding-relocation-information-in-fips-validated-libeay32-dll/36271778

I'm aware of a few solutions, which probably won't help you at all:
- Switch to 64-bit.
- Switch to Linux or UNIX. This is primarily (exclusively?) a Windows problem, because of how the PE loader handles relocations; I'm not aware of another OpenSSL platform that has it. Though without looking I don't know which platforms have a recent OpenSSL FIPS validation, either.
- Switch to a FIPS-validated hardware crypto implementation, and either wire OpenSSL to it using the ENGINE mechanism, or use a different TLS implementation.
- Put more constraints on the loader, for example by statically linking what you can, and forcing other DLLs to load at other addresses (e.g. by setting preferred bases, etc). In specific cases this may give you sufficient control; in the general case it's a losing battle. Load libeay as early as possible.
- Put all your TLS processing in a separate service process that includes the bare minimum of code and no DLLs other than OpenSSL; you might even link OpenSSL statically. Use IPC to communicate between this TLS service process and your application. Obviously there are performance and security issues, though they're acceptable for some applications. You can control how the stripped-down service process lays out its memory.

All that said, I've never looked into this problem closely (I avoid the FIPS-validated build as much as I possibly can), so someone else may well have better suggestions.


Michael Wojcik 
Distinguished Engineer, Micro Focus