Page MenuHome GnuPG

Fix check_binary_integrity
Open, NormalPublic

Description

The configure option --enable-hmac-binary-check, which defines ENABLE_HMAC_BINARY_CHECK macro seems to have never worked, and keeps status of expressing the concept;

dladdr requires an address as the first argument, but currently it's symbol name.

SUSE has a patch, but... AFAIK, it is wrong for ELF system to load same shared object/libraries more than once (as its name space is single). So, use of dlopen here is wrong.

Event Timeline

gniibe triaged this task as Normal priority.Aug 6 2021, 9:37 AM
gniibe created this task.

Just for the records, the whole HMAC thing including the special dlopen trick used to work fine when we did the original FIPS support.

We have the same patch (including the hmac key and we use the switch. The reasoning on our side was to be compatible with fipscheck, but it is no longer used since last year and we use just the hmac256 tool:

https://src.fedoraproject.org/rpms/libgcrypt/blob/rawhide/f/libgcrypt.spec#_121

Let me check if there is some specific requirement for the hmac files in FIPS 140-3

Ah... I realized that HMAC integrity check with dladdr (using address of constant string) might work (at some point) to determine the filename of libgcrypt.so, when/if glibc implementation allows searching with address of constant string. So, my claim "never worked" was wrong.

Now, with rCc9acca86, we use dladdr1 to determine the file name of libgcrypt.so, and the offset in the file for HMAC value. Please note that: The HMAC value is written in libgcrypt.so itself (it was an independent file in the past, named like .libgcrypt.so.20.3.3.hmac). In current implementation, we use .rodata1 section for that, following some practice of embedded system. If it is not good, we can change the way where we keep the HMAC value.

This feature is only supported for GNU/Linux with shared library (not for static link), because dl functions are non-POSIX (or not-yet POSIX) thing.

While I don't know if runtime integrity check is required or not by FIPS 140,
I checked OpenSSL, and it has such a check in openssl/providers/fips. The FIPS module configuration file which has the module checksum by HMAC is generated by openssl fipsinstall command.

iirc Uli Drepper added a hack to dladdr which we made use of. Seems to be integrated into dladdr1 now.

I tried to generate a tarball from master and I failed to build the hmac256 binary because the hmac256.h was not packaged into the dist tarball in master. If hmac256 should be standalone binary, I propose it should not need have a separate header file:

Other option might be adding back the header file, probably to EXTRA_DIST in Makefile.am to unbreak the build. What do you think @gniibe ?

Thank you for pointing out. Since hmac256.{c,h} can be used by others, I think that it is better to keep those two files, instead of merging it into one.

https://www.gnu.org/software/automake/manual/html_node/Headers.html#Headers says:

However when the header actually belongs to a single convenience library or program, we recommend listing it in the program’s or library’s _SOURCES variable...

So, I'm adding hmac256.h to hmac256_SOURCES.

Thanks. This looks good to me.

I tested also the hmac binary check itself with the hmac inside of the library and all seems to work great.

I only found quite cumbersome the way to change the key. Its hardcoded in the source code on two places so when I need to use different key, I need to patch it in two places. I would suggest to provide a configure switch with the key, which would be used both for hmac generation (variable in src/hmac256.c) and verification (constant in src/fips.c).