Static FIPS Library with Address Randomization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Static FIPS Library with Address Randomization

Neptune
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?

Thanks - any ideas are greatly appreciated. Even if this is mission impossible, at least I'll have something to report. If we need to apply for an exception to one or more NIAP requirements so be it, but I want to exhaust all possibilities.

Thanks,
Paul
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Static FIPS Library with Address Randomization

Michael Wojcik

> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Neptune
> Sent: Friday, March 17, 2017 09:26
> To: [hidden email]
> 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Static FIPS Library with Address Randomization

wrowe
On Fri, Mar 17, 2017 at 12:06 PM, Michael Wojcik
<[hidden email]> wrote:

>
>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Neptune
>> Sent: Friday, March 17, 2017 09:26
>> To: [hidden email]
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Static FIPS Library with Address Randomization

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of William A Rowe Jr
> Sent: Monday, March 20, 2017 20:59
> To: [hidden email]
> Subject: Re: [openssl-users] Static FIPS Library with Address Randomization
>
> 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.

Yes. That's what /BASE:x /FIXED does, which causes the problem (address not available at runtime) which the OP was trying to work around. We're just back where we started.

The simple fact of the matter is that the FIPS requirements do not play well with the PE DLL design. Arguably the PE DLL design itself is at fault (PE relocations also inhibit sharing text pages among processes, for example), but it is what it is. In 32-bit, address space is a scarce resource, and OSes make various compromises in managing it. The real problem is that FIPS 140-2 was written primarily for hardware and doesn't accommodate software well. And, many have argued, doesn't really do anything useful anyway - which is no help whatsoever if your customer is required to have it, or insists on it anyway.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Static FIPS Library with Address Randomization

Jakob Bohm-7
On 21/03/2017 14:02, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of William A Rowe Jr
>> Sent: Monday, March 20, 2017 20:59
>> To: [hidden email]
>> Subject: Re: [openssl-users] Static FIPS Library with Address Randomization
>>
>> 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.
> Yes. That's what /BASE:x /FIXED does, which causes the problem (address not available at runtime) which the OP was trying to work around. We're just back where we started.
>
> The simple fact of the matter is that the FIPS requirements do not play well with the PE DLL design. Arguably the PE DLL design itself is at fault (PE relocations also inhibit sharing text pages among processes, for example), but it is what it is. In 32-bit, address space is a scarce resource, and OSes make various compromises in managing it. The real problem is that FIPS 140-2 was written primarily for hardware and doesn't accommodate software well. And, many have argued, doesn't really do anything useful anyway - which is no help whatsoever if your customer is required to have it, or insists on it anyway.
>
I don't believe it is a shortcoming of FIPS 140-2 as much as it
is a shortcoming of how the OpenSSL library verifies the hash of
the FIPS blob.  Specifically, that the has verification is done
on the runtime-relocated code block, not on it's
unrelocated/normalized form.

If there is a conformant way to change the code that checks the
FIPS blob, so it checks the "relocated-to-base-0" form along with
the list of blob-relative relocation offsets used for that
normalization, then the blob hash should work fine with runtime
relocation to an available address, address-layout randomization
etc.  The list of relocation offsets could be trivially extracted
from the relocation data in any non-fixed PE file linked against
that particular blob, sorted by address and filtered to only
include those offsets that fall within the blob.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Static FIPS Library with Address Randomization

Steve Marquess-4
On 03/21/2017 10:17 AM, Jakob Bohm wrote:

> On 21/03/2017 14:02, Michael Wojcik wrote:
>>> From: openssl-users [mailto:[hidden email]] On Behalf
>>> Of William A Rowe Jr
>>> Sent: Monday, March 20, 2017 20:59
>>> To: [hidden email]
>>> Subject: Re: [openssl-users] Static FIPS Library with Address
>>> Randomization
>>>
>>> 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.
>> Yes. That's what /BASE:x /FIXED does, which causes the problem
>> (address not available at runtime) which the OP was trying to work
>> around. We're just back where we started.
>>
>> The simple fact of the matter is that the FIPS requirements do not
>> play well with the PE DLL design. Arguably the PE DLL design itself is
>> at fault (PE relocations also inhibit sharing text pages among
>> processes, for example), but it is what it is. In 32-bit, address
>> space is a scarce resource, and OSes make various compromises in
>> managing it. The real problem is that FIPS 140-2 was written primarily
>> for hardware and doesn't accommodate software well. And, many have
>> argued, doesn't really do anything useful anyway - which is no help
>> whatsoever if your customer is required to have it, or insists on it
>> anyway.
>>
> I don't believe it is a shortcoming of FIPS 140-2 as much as it
> is a shortcoming of how the OpenSSL library verifies the hash of
> the FIPS blob.  Specifically, that the has verification is done
> on the runtime-relocated code block, not on it's
> unrelocated/normalized form.
>
> If there is a conformant way to change the code ...

And therein lies the rub, because converging on the "incore" scheme we
use was a long and tortuous process that left us with what the CMVP
would accept, not what we preferred. We discovered that the CMVP had
some rather subtle ideological requirements for the integrity digest.

The scheme they are most familiar with is a digest over a shared library
file. Our first thought was just to do a digest over the application
executable file containing the FIPS module (which in many cases would be
a shared library), but that was specifically rejected (see section 2.2
of the OpenSSL FIPS module user guide,
https://www.openssl.org/docs/fips/UserGuide-2.0.pdf).

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 301 874 2571
[hidden email]
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Static FIPS Library with Address Randomization

Jakob Bohm-7
On 21/03/2017 16:06, Steve Marquess wrote:

> On 03/21/2017 10:17 AM, Jakob Bohm wrote:
>> On 21/03/2017 14:02, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>>>> Of William A Rowe Jr
>>>> Sent: Monday, March 20, 2017 20:59
>>>> To: [hidden email]
>>>> Subject: Re: [openssl-users] Static FIPS Library with Address
>>>> Randomization
>>>>
>>>> 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.
>>> Yes. That's what /BASE:x /FIXED does, which causes the problem
>>> (address not available at runtime) which the OP was trying to work
>>> around. We're just back where we started.
>>>
>>> The simple fact of the matter is that the FIPS requirements do not
>>> play well with the PE DLL design. Arguably the PE DLL design itself is
>>> at fault (PE relocations also inhibit sharing text pages among
>>> processes, for example), but it is what it is. In 32-bit, address
>>> space is a scarce resource, and OSes make various compromises in
>>> managing it. The real problem is that FIPS 140-2 was written primarily
>>> for hardware and doesn't accommodate software well. And, many have
>>> argued, doesn't really do anything useful anyway - which is no help
>>> whatsoever if your customer is required to have it, or insists on it
>>> anyway.
>>>
>> I don't believe it is a shortcoming of FIPS 140-2 as much as it
>> is a shortcoming of how the OpenSSL library verifies the hash of
>> the FIPS blob.  Specifically, that the has verification is done
>> on the runtime-relocated code block, not on it's
>> unrelocated/normalized form.
>>
>> If there is a conformant way to change the code ...
> And therein lies the rub, because converging on the "incore" scheme we
> use was a long and tortuous process that left us with what the CMVP
> would accept, not what we preferred. We discovered that the CMVP had
> some rather subtle ideological requirements for the integrity digest.
>
> The scheme they are most familiar with is a digest over a shared library
> file. Our first thought was just to do a digest over the application
> executable file containing the FIPS module (which in many cases would be
> a shared library), but that was specifically rejected (see section 2.2
> of the OpenSSL FIPS module user guide,
> https://www.openssl.org/docs/fips/UserGuide-2.0.pdf).
>
> -Steve M.
>
Rereading section 2.2 and 2.3 of the UserGuide didn't really give any
reason preventing the creation of an algorithm that checks the required
code and data segment portions (as it does today), but applies a
"normalization" conceptually similar to how signature checking on S/MIME
requires line ending normalization before passing data to the hash
algorithm.

The text did however seem to indicate that the checking code is inside
the blob and thus requires an updated validation in order to be modified.

An alternative approach would be to somehow coach some Windows compiler
into generating truly position-independent code and data for the blob,
however that too would probably require revalidation.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Loading...