[openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"

[Andy Polyakov via RT]

> Use an older version of OpenSSL for your FIPS-enabled OpenSSL?

For this specific problem it wouldn't help. I mean even older versions
should/would exhibit same problem. And renaming symbols or removing
.global directives (in whatever OpenSSL version being linked with FIPS
module, not FIPS module) would have to be performed for all of them. The
reason for why the problem in question (and similar) slip through is
that FIPS module validation procedure, exhausting as it is, does not
involve linking with "big" OpenSSL. As result one risks to remain
oblivious of them on rare platforms such as one in question till it
becomes too late. But luckily enough one can modify "big" OpenSSL to
accommodate such mishaps. Renaming symbols as general method or
case-specific workarounds like removing .global directives in this case
is the way to go.

> Yes,
> it might have security problems, but it you’re using the FIPS module!
> It’s got worse security problems, so you shouldn’t worry. :)
> 
> I can say for sure the FIPS 2.0 module compiled and worked at the
> time the Security Policy was approved for HP-UX on IA64 and PA-RISC,
> in both 32- and 64-bit flavors. But it was pretty picky about the
> link editor and compiler.
> 
> Two other issues to be aware of (and maybe fixing this will let the
> more recent versions of OpenSSL work):
> 
> 1) HP’s link editor is very brittle. You should be sure you’re using
> the proper patch level for it.  I no longer have access to the box I
> was building on, and I’m not sure what the status of the box that was
> sent for testing is, so I can’t check the patch-level for the link
> editor.  Take a look at the dates in the Security Policy, it was the
> patch that came out about a month (or less?) prior to the submission
> of the FIPS 2.0 module for approval.  The previous patch wouldn’t
> link anything except the HP-UX kernel, so it was released outside the
> normal schedule (and the next patch broke it again, the patch after
> that was OK, but I never tried that one with building the FIPS module
> or FIPS-enabled OpenSSL).
> 
> 2) You’re definitely using a newer version of the compiler; A.06.25
> was the current version when the FIPS stuff was approved; depending
> on your auditors, you may need to be using that one.  Especially
> since the prior versions wouldn’t compile the FIPS module correctly,
> I wouldn’t be surprised if newer ones are incapable, too.

Seconded.