openssl: dsaparam and dhparm are broken

Trying to repair the tests in test/recipes/90-test_store.t for #11733 I’ve come across nice crashes of dsaparam.

Calling it with a key size acceptable these days, e.g., 2048:

apps/openssl dsaparam  -out dsaparam.pem 2048

apps/openssl dsaparam -genkey -out dsakey.pem 2048

one gets for instance

==11521==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f6239ee36d8 bp 0x7fff02e120f0 sp 0x7fff02e12050 T0)
==11521==The signal is caused by a WRITE memory access.
==11521==Hint: address points to the zero page.
    #0 0x7f6239ee36d8 in ossl_callback_to_pkey_gencb crypto/evp/pmeth_gn.c:136
    #1 0x7f623a127516 in dsa_gencb providers/implementations/keymgmt/dsa_kmgmt.c:487
    #2 0x7f6239d002f5 in BN_GENCB_call crypto/bn/bn_prime.c:115
    #3 0x7f6239ef4091 in generate_q_fips186_4 crypto/ffc/ffc_params_generate.c:290
    #4 0x7f6239ef54e5 in ffc_params_FIPS186_4_gen_verify crypto/ffc/ffc_params_generate.c:634
    #5 0x7f6239ef71b3 in ffc_params_FIPS186_4_generate crypto/ffc/ffc_params_generate.c:982
    #6 0x7f6239db6b1f in dsa_generate_ffc_parameters crypto/dsa/dsa_gen.c:46
    #7 0x7f623a1279b5 in dsa_gen providers/implementations/keymgmt/dsa_kmgmt.c:528
    #8 0x7f6239ec5b58 in evp_keymgmt_gen crypto/evp/keymgmt_meth.c:335
    #9 0x7f6239ec3587 in evp_keymgmt_util_gen crypto/evp/keymgmt_lib.c:413
    #10 0x7f6239ee3cf8 in EVP_PKEY_gen crypto/evp/pmeth_gn.c:190
    #11 0x7f6239ee4358 in EVP_PKEY_paramgen crypto/evp/pmeth_gn.c:276
    #12 0x44daa7 in dsaparam_main apps/dsaparam.c:184
    #13 0x465fc1 in do_cmd apps/openssl.c:467
    #14 0x46528c in main apps/openssl.c:279

It turns out that ossl_callback_to_pkey_gencb() tries to assign

    ctx->keygen_info[0] = p;
    ctx->keygen_info[1] = n;

while ctx->keygen_info == NULL because the ctx is not properly initialized. I tried to fix this myself but this goes beyond my OpenSSL knowledge. It looks like this is due to a mistake in the recent switch to the provider mechanism, and unfortunately there is no test at least at CLI level that would have caught this.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 17 (17 by maintainers)

Commits related to this issue

EVP: Let EVP_PKEY_gen() initialize ctx->keygen_info In EVP_PKEY_METHOD code, the backend initializes ctx->keygen_info. With provider side code, it's not possible to reach back into the EVP_PKEY_CTX i... — committed to levitte/openssl by levitte 4 years ago

Most upvoted comments

# openssl dsaparam -genkey 1024
Error, DSA key generation failed
The default qbits genctx value (224) set by dsa_gen_init() is never updated. As the L/N values don’t match, ffc_validate_LN() returns 0 instead of the security strength, causing a generation failure.

This particular use case still doesn’t seem to work even with #12072 commits:

# openssl dsaparam -genkey 3072
Error, DSA key generation failed
unable to load DSA parameters

The N value still remains hardcoded to 224 for all numbits values.

ciz on Jun 10, 2020

Note that there are other things that aren’t quite right with these two apps. I did a bit of cleanup during the weekend, see #12072

levitte on Jun 8, 2020

I think there is often a confusion in our tests about what exactly it is that we’re testing. In an ideal world we would have:

Command line tests that are intended to test the command line application
Library tests to test the proper functioning of the library

It is often an unclear in our tests where we use the command line which one of those two we are targeting. Often it is a blend of both which is unfortunate.

mattcaswell on Jun 8, 2020

I wonder why there are apparently no tests for those apps,

Because all tests have moved to use openssl genpkey, openssl pkeyparam, openssl pkey and openssl pkeyutl, which were built to supercede the algorithm specific commands. A recent move had us rewrite the algorithm specific commands in EVP_PKEY terms, but apparently with some glitches. The unfortunate result is that we now have 3 different commands doing almost exactly the same thing (at least in terms of EVP_PKEY functions), and that’s just for param generation…

levitte on Jun 5, 2020

This isn’t particularly about dsaparam, it’s a fault in EVP_PKEY_gen(), which should have initialized ctx->keygen_info to allow legacy compatible callbacks to work right.

Fix coming up.

levitte on Jun 4, 2020