fipsld fails when CC=g++
Marty Lamb
I am trying to build a C++ application using OpenSSL-fips-1.0. The
application compiles and runs fine (sans FIPS_mode_set()) when simply
compiled using g++.
However, when "CC=gcc fipsld" is used, the following error results:
/usr/local/ssl/bin/../lib/fips_premain.c:66: error: initializer-string
for array of chars is too long
The line in question (line 66 of fips_premain.c) is:
static const unsigned char FINGERPRINT_ascii_value[40] = HMAC_SHA1_SIG;
As far as I can tell this looks like an off by one error (no room in
array for null terminator). Of course, I cannot modify fips_premain.c
and still run fipsld.
My compiler version is: g++ (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)
This is trivial to test using the following program:
int main(int argc, char **argv) {
return 0;
}
Am I missing something?
Thanks,
Marty
--
Marty Lamb
Rajant Corporation
610-873-6788
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Marty Lamb
> However, when "CC=gcc fipsld" is used, the following error results:
Should instead be
> However, when "CC=g++ fipsld" is used, the following error results:
Sorry for any confusion. Any help would be very much appreciated.
- Marty
--
Marty Lamb
Rajant Corporation
610-873-6788
Marty Lamb wrote:
> Hello,
>
> I am trying to build a C++ application using OpenSSL-fips-1.0. The
> application compiles and runs fine (sans FIPS_mode_set()) when simply
> compiled using g++.
>
> However, when "CC=gcc fipsld" is used, the following error results:
>
> /usr/local/ssl/bin/../lib/fips_premain.c:66: error: initializer-string
> for array of chars is too long
>
> The line in question (line 66 of fips_premain.c) is:
>
> static const unsigned char FINGERPRINT_ascii_value[40] = HMAC_SHA1_SIG;
>
> As far as I can tell this looks like an off by one error (no room in
> array for null terminator). Of course, I cannot modify fips_premain.c
> and still run fipsld.
>
> My compiler version is: g++ (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)
>
> This is trivial to test using the following program:
>
> int main(int argc, char **argv) {
> return 0;
> }
>
> Am I missing something?
>
> Thanks,
>
> Marty
>
______________________________________________________________________
Kyle Hamilton
to be addressed. (HMAC_SHA1_SIG is defined as a string with a nil
terminator. gcc doesn't throw the error, but g++ rightly does. I
think there's a command-line parameter to disable that particular
error check, but I'm not sure -- but, as a possible workaround, you
might be able to use gcc to call fipsld and use g++ for everything
else.)
The proper definition would be in explicit declarative mode, as
opposed to string mode. (that is, { 's', 't', 'r', ... }; instead of
"stringhere"). It's difficult to update, though, as any modification
of the -fips tarball invalidates the FIPS certification. (I'd like to
see a FIPS validation system, as defined by the FIPS testing criteria,
built for OpenSSL, in order to validate that any changes to the source
tree won't cause a recertification to fail, and to perhaps fast-track
any bugfixed code through a recertification. The cost of a
recertification is not trivial, though...)
Steve: If you know how much the original certification cost, could you
perhaps mention it? Or would you be able to point to someone I could
ask?
-Kyle H
Marty Lamb
> No, you got the problem exactly right, and it is a bug that does need
> to be addressed. (HMAC_SHA1_SIG is defined as a string with a nil
> terminator. gcc doesn't throw the error, but g++ rightly does. I
> think there's a command-line parameter to disable that particular
> error check, but I'm not sure -- but, as a possible workaround, you
> might be able to use gcc to call fipsld and use g++ for everything
> else.)
Thanks. At least now I know I'm not crazy. I searched for a g++
command line parameter to disable that check, but couldn't find anything.
Just a few minutes ago, however, I discovered exactly the solution you
suggest. Compile everything (c and c++) into object files using
whatever compiler is appropriate, then use gcc with fipsld to link, but
manually specify the c++ library for the linker:
CC=gcc fipsld ... -lstdc++
This works fine, and does not appear to violate any of the OpenSSL FIPS
criteria. It might even be obvious to developers used to mixing C and
C++ (unlike myself. :)
> (I'd like to
> see a FIPS validation system, as defined by the FIPS testing criteria,
> built for OpenSSL, in order to validate that any changes to the source
> tree won't cause a recertification to fail, and to perhaps fast-track
> any bugfixed code through a recertification. The cost of a
> recertification is not trivial, though...)
That would be great. And I'm sure that there are plenty of parties who
would be more than happy to help fund recertifications for future bug fixes.
Thanks for the response and the dead-on solution.
- Marty
--
Marty Lamb
Rajant Corporation
610-873-6788
marq...@oss-institute.org
>
> No, you got the problem exactly right, and it is a bug that
> does need to be addressed. (HMAC_SHA1_SIG is defined as a
> string with a nil terminator. gcc doesn't throw the error,
> but g++ rightly does. I think there's a command-line
> parameter to disable that particular error check, but I'm not
> sure -- but, as a possible workaround, you might be able to
> use gcc to call fipsld and use g++ for everything
> else.)
>
> as opposed to string mode. (that is, { 's', 't', 'r', ... };
> instead of "stringhere"). It's difficult to update, though,
> as any modification of the -fips tarball invalidates the FIPS
> defined by the FIPS testing criteria, built for OpenSSL, in
> order to validate that any changes to the source tree won't
> cause a recertification to fail, and to perhaps fast-track
> any bugfixed code through a recertification. The cost of a
> recertification is not trivial, though...)
The pieces for such a FIPS 140-2 regression test are more or less in
place, in the form of the algorithm test drivers and the "fips_test_suite=
"
test program. The use of those test utilities is documented in the FIPS
Object Module User Guide.
> Steve: If you know how much the original certification cost,
> could you perhaps mention it? Or would you be able to point
> to someone I could ask?
It's hard to put a price tag on the overall OpenSSL FIPS object module
validation effort (not certification, BTW) for several reasons. One is
that this validation was unique as the first ever validated product
delivered in source form, in the amount of time and effort expended over
3-1/2 years, and in the amount of external opposition encountered. A
great deal of non-compensated labor was contributed, in addition to the
US$120,000+ of initial cash funding. I guesstimate the total effort woul=
d
easily have exceeded half a million bucks if the non-cash contributions
were accounted for at fair market rates.
A revalidation should be much simpler and cheaper, fortunately. John
Weathersby of the OSSI (www.oss-institute.org) is currently working on
coordinating a follow-up validation with interested sponsors. What that
revalidation will include and what it will cost will depend on the
sponsors he signs up.
-Steve M.
--=20
Steve Marquess
Veridical Systems, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
301-524-9915 cell
301-831-8447 land/fax
marq...@veridicalsystems.com