Using RAND_status()

[Dr. Matthias St. Pierre]

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 at openssl.org> On Behalf Of Jayme Mikko Ancla
Sent: Thursday, February 16, 2023 12:48 AM
To: Tomas Mraz <tomas at openssl.org>; Jayme Mikko Ancla <jaymemikko at gmail.com>; openssl-users at openssl.org
Subject: Re: Using RAND_status()

Hi all,

Thanks for the replies.
I checked our original code and made sure that we use Default and Legacy providers. (looks like I omitted it in my first email).
Some info:
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.

Regards,
Jayme

On Thu, Feb 16, 2023 at 3:46 AM Steffen Nurpmeso <steffen at sdaoden.eu<mailto:steffen at sdaoden.eu>> wrote:
Tomas Mraz wrote in
 <a73ba399390924cb0249146723d43babf485674d.camel at openssl.org<mailto:a73ba399390924cb0249146723d43babf485674d.camel at openssl.org>>:

(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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230318/b26397fd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 10508 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230318/b26397fd/attachment-0001.p7s>