There is absolutely no need anymore to call
RAND_status() or do any specific initialization, starting from version 1.1.1.
The DRBG is initialized on first use, and your call to
RAND_status() just happens to be the first use.
Indeed, the call stack you posted looks like the crash happens
in the middle of the initialization process, which uses an
AES-CTR internally. Since the does not occur without
PurifyPlus, there are two possibilities:
- Purify
detected a problem (e.g. an out-of-bound memory access)
- The
hooking by Purify is causing the problem
In the former case I’d expect a diagnostic message from Purify,
before it calls abort() explicitly. But what I see is an abort()
triggered by an unhandled SEH exception. You might want to
run your program in the Debugger, it will catch the throw
directly and you might be able see what type of exception is
raised.
Matthias
From:
openssl-users <openssl-users-bounces@xxxxxxxxxxx>
On Behalf Of Jayme Mikko Ancla
Sent: Thursday, February 16, 2023 12:48 AM
To: Tomas Mraz <tomas@xxxxxxxxxxx>; Jayme Mikko Ancla <jaymemikko@xxxxxxxxx>; openssl-users@xxxxxxxxxxx
Subject: Re: Using RAND_status()
Hi all,
I checked our original code and made sure that we use Default and Legacy providers. (looks like I omitted it in my first email).
OpenSSL Version: 3.0.5
Commands for building OpenSSL: perl Configure VC-WIN32 --prefix=C:/openssl-3.0.5-debug-vc19 --debug
Compiler used(for our program and OpenSSL build): Visual Studio 2019
Platform: Windows 10 22H2 64bit
Note that there is no problem with these sequences of code during
runtime.
BUT, whenever we enable our memory leak detection software
PurifyPlus then run our program, RAND_status() encounters problems which then terminates the program.
[I] Message: TerminateProcess called with code 0x3
Call location
TerminateProcess [C:\Windows\SysWOW64\KERNEL32.DLL]
common_message_window<wchar_t> [.\minkernel\crts\ucrt\src\appcrt\misc\dbgrpt.cpp:432]
exit_err [<REPO>\main.c:521]
__scrt_common_main_seh [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:304]
_aesni_cbc_encrypt [C:\thirdparty\openssl\openssl-3.0.5-debug\openssl-3.0.5\crypto\aes\libcrypto-shlib-aesni-x86.obj]
_aesni_set_encrypt_key [C:\thirdparty\openssl\openssl-3.0.5-debug\openssl-3.0.5\crypto\aes\libcrypto-shlib-aesni-x86.obj]
cipher_hw_aesni_initkey [C:\thirdparty\openssl\openssl-3.0.5-debug\openssl-3.0.5\providers\implementations\ciphers\cipher_aes_hw_aesni.inc:37]
cipher_generic_init_internal [C:\thirdparty\openssl\openssl-3.0.5-debug\openssl-3.0.5\providers\implementations\ciphers\ciphercommon.c:218]
ossl_cipher_generic_einit [C:\thirdparty\openssl\openssl-3.0.5-debug\openssl-3.0.5\providers\implementations\ciphers\ciphercommon.c:228]
evp_cipher_init_internal [C:\thirdparty\openssl\openssl-3.0.5-debug\openssl-3.0.5\crypto\evp\evp_enc.c:218]
The program terminates at _aesni_cbc_encrypt.
Are there some pointers we have to initialize or functions to call before calling RAND_status()?
I also checked about RAND_DRBG_set_reseed_defaults but it seems already removed from 3.0.0.
Tomas Mraz wrote in
<a73ba399390924cb0249146723d43babf485674d.camel@xxxxxxxxxxx>:
(Resorting a bit)
|On Wed, 2023-02-15 at 12:00 +0800, Jayme Mikko Ancla wrote:
|> I would like to know if my use of RAND_status() like below is
|> correct:
...
|> if (RAND_status() != 1) {
|> RAND_seed(rnd_seed, sizeof rnd_seed);
|> }
...
|I assume you're getting a failure. If so, it is because you did
|not load the default provider in addition to the legacy one.
|
|Otherwise your code is OK, although these days the RAND_seed() call
Has this changed again? I am now forced to set
(void)RAND_DRBG_set_reseed_defaults(0, 0, 0, 0); /* (does not fail here) */
and especially i call anything in a loop as in
# if mx_HAVE_TLS != mx_TLS_IMPL_RESSL && !defined mx_XTLS_HAVE_RAND_FILE
n_err(_("TLS RAND_bytes(3ssl) failed (missing entropy?), "
"waiting a bit\n"));
/* Around ~Y2K+1 anything <= was a busy loop iirc, so give pad */
su_time_msleep(250, FAL0);
continue;
# endif
|should not be needed at all, the RNG should be seeded by itself unless
|there is something wrong with your build configuration of the OpenSSL
|or your OS is some awkward legacy one.
Ah the OS! "32 byte is enough"(, endlessly), said Jason Donenfeld.
(Reseeded often, and pretty "nifty", imho. Once i looked.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
