On Fri, Mar 17, 2017 at 12:06 PM, Michael Wojcik <michael.woj...@microfocus.com> wrote: > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of Neptune >> Sent: Friday, March 17, 2017 09:26 >> To: openssl-users@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.
Note you may not modify the openssl-FIPS build files or process. However, building the openssl host container of the FIPS library build, you may pin the DLL file with link flags and dodge this relocation. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
