On 9/6/2013 6:26 PM, Perrow, Graeme wrote:
I am having trouble loading the OpenSSL FIPS DLLs (2.0.5, using OpenSSL
1.0.1e) in my 32-bit Windows application. Most of the time I get a
“fingerprint does not match” error from FIPS_mode_set but now and again,
with no code changes, it succeeds. I have a feeling it has to do with
“rebasing” and where the DLL is loaded into memory.
Running dumpbin on libeay32.dll shows an image base of “FB0” which I
believe is correct. My application executable loads a DLL which loads a
second DLL, and that second DLL is the one that loads the FIPS DLLs. My
DLLs are built with /FIXED:NO and /BASE: with a specific address. I have
made no changes to the OpenSSL build procedure.
My problem is that I don’t understand rebasing well enough to know if I
need to build my DLLs differently, or if I need to tweak the OpenSSL
build procedure.
I was seeing a similar problem on 64-bit Windows for a while but that
error just “magically” went away and I haven’t seen it since. I’m
worried that the 64-bit problem is still there and I’m just getting lucky.
Rebasing is like relinking with a new value of /BASE:, but with the
linker magically making all the same decisions and without needing
access to the original .obj and .lib files.
Rebasing is also like loading a DLL into a process where its preferred
address is already in use by another allocation or DLL, causing the
loader to load it at a different address and applying the relocation
table in the DLL file to make the code work at the new address. This
is in fact the secret to how the rebasing tools work without source
code access.
The big problem is that the FIPS fingerprinting method used by OpenSSL
seems to assume that the code will never be relocated between the time
the fingerprint was generated by an app developer and the time when the
code checks the fingerprint, which is a false assumption on any
platform that does address space layout randomization and a dubious
assumption on any dynamic platform.
So I would suggest that any Windows file containing the FIPS module (be
it a DLL or an EXE), needs to be linked with /FIXED to make it
loadable only at the address specified with /BASE and neither
relocatable nor rebasable. The effect of this is that Windows will then
try as hard as possible to load it at the specified base address or
report an explicit error otherwise. Official Microsoft guidelines
suggest that the fixed base for a DLL should be in the range 0x5000
to 0x6FFF on 32 bit platforms and much higher on 64 bit platforms,
however you need to scan other (system and application) DLLs to make
sure you don't choose an address range used by any other DLL likely to
be loaded into your process. EXE files should use the default /BASE
value in any post-1997 linker (a few very old linkers used a different
value not compatible with later platforms but the new value is
backwards compatible).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
