Use of HMAC (stand-alone)

[Tickerguy]

I am using the "allegedly currently valid to use" HMAC function in a stand-alone program -- no other OpenSSL functions.  It correctly computes the HMACs that I need to validate an incoming data stream (from Stripe, if it matters.)

The documentation SAYS I do not need to clean up or initialize the engine when using this -- and only this -- function.   I am NOT passing it NULL for the output buffer (that is, I'm handing it an existing and known good buffer for the MAC); the call is:

sigptr = HMAC(EVP_sha256(), sec_it, strlen(sec_it), (unsigned char *) in, strlen(in), signature, &siglen);

"signature" is defined as:

static  unsigned char   signature[EVP_MAX_MD_SIZE];

So there should be no issue with any possible overflow nor am I requesting a dynamic allocation for the signature from the library.

However, sometimes (not in every case) on exit (normal termination, exit(0)) I am getting a core dump with a SEGV in some part of the OpenSSL cleanup code which appears to have hooked _atexit.

Do I need to issue OPENSSL_init() and OPENSSL_cleanup() calls to avoid this?  It doesn't impact the function of the executable itself since it occurs after all internal cleanup is complete, but the log entries for the SEGV are more than a bit annoying.  They do not occur in *every* instance either.

[Neil Horman]

What version of openssl are you using, and do you have a reproducer program you can share that illustrates the problem (or a backtracke of the segfault)?

Neil

--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-user...@openssl.org.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/0547ec2e-d326-4945-9ee8-594fbd38a939n%40openssl.org.

[Tickerguy]

$ openssl version
OpenSSL 3.0.16 11 Feb 2025 (Library: OpenSSL 3.0.16 11 Feb 2025)

I do not have a reproducer, but do have a backtrace on the crash:

(lldb) bt
* thread #1, name = 'stripe-event', stop reason = signal SIGSEGV
  * frame #0: 0x00000008219aaa22 libc.so.7`___lldb_unnamed_symbol6062 + 1106
    frame #1: 0x0000000821961f9a libc.so.7`___lldb_unnamed_symbol5411 + 874
    frame #2: 0x0000000822fef234 libcrypto.so.30`___lldb_unnamed_symbol10853 + 68
    frame #3: 0x0000000822e6087f libcrypto.so.30`___lldb_unnamed_symbol8468 + 191
    frame #4: 0x0000000822fef1b6 libcrypto.so.30`___lldb_unnamed_symbol10852 + 38
    frame #5: 0x0000000822e528f2 libcrypto.so.30`CRYPTO_free_ex_data + 402
    frame #6: 0x0000000822e4eae2 libcrypto.so.30`___lldb_unnamed_symbol8205 + 98
    frame #7: 0x0000000822e4ea70 libcrypto.so.30`___lldb_unnamed_symbol8204 + 16
    frame #8: 0x0000000822e52dc0 libcrypto.so.30`OPENSSL_cleanup + 224
    frame #9: 0x000000082194bec4 libc.so.7`__cxa_finalize + 356
    frame #10: 0x000000082194c46c libc.so.7`exit + 76
    frame #11: 0x0000000000207970 stripe-event`main(argc=1, argv=0x0000000820c79b98) at stripe-event.c:1052:2
    frame #12: 0x000000082186be34 libc.so.7`__libc_start1 + 292
    frame #13: 0x00000000002044e4 stripe-event`_start at crt1_s.S:80
(lldb)

One other piece of information that may be relevant -- the application in question is also linked with Postgres' libpq (-lpq -lcrypto) as it performs database functions, and Postgres was built with SSL support.  The application has called "PQfinish()" (to clean up any of Postgres' internal allocations) before it calls exit(0).