Pass zero-length parameters to providers #11920
Closed
Conversation
|
Oops, the "regression from 1.1.1 for HKDF" seems to be premature (and I'll need to adjust the commit message); I had started my development on master but forgotten the details of the report I actually received. |
crypto/params.c
Outdated
Show resolved
Hide resolved
Add an extra EVP test that provides empty input key material. It currently fails, since we lose the information about "key present but zero length" as we deserialize parameters in the provider.
Prior to this commit, if a string (or octet string) parameter was present but indicated it was zero-length, we would return success but with a NULL output value. This can be problematic in cases where there is a protocol-level distinction between parameter-absent and parameter-present-but-zero-length, which is uncommon but can happen. Since OPENSSL_malloc() returns NULL for zero-length allocation requests, make a dummy allocation for this case, to give a signal that the string parameter does exist but has zero length.
As of the previous commit, when a zero-length (string) parameter is present in the parameters passed to a provider for a given operation, we will produce an object corresponding to that zero-length parameter, indicating to the underlying cryptographic operation that the parameter was passed. However, rsa_cms_decrypt() was relying on the previous behavior, and unconditionally tried to call EVP_PKEY_CTX_set0_rsa_oaep_label() even when the implicit default label was used (and thus the relevant local variable was still NULL). In the new setup that distinguishes present-but-empty and absent more clearly, it is an error to attempt to set a NULL parameter, even if it is zero-length. Exercise more caution when setting parameters, and do not call EVP_PKEY_CTX_set0_rsa_oaep_label() when there is not actually a label provided.
|
force-pushed with updated commit messages and the change that @levitte requested. |
|
This pull request is ready to merge |
openssl-machine
pushed a commit
that referenced
this pull request
May 28, 2020
Add an extra EVP test that provides empty input key material. It currently fails, since we lose the information about "key present but zero length" as we deserialize parameters in the provider. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #11920)
openssl-machine
pushed a commit
that referenced
this pull request
May 28, 2020
Prior to this commit, if a string (or octet string) parameter was present but indicated it was zero-length, we would return success but with a NULL output value. This can be problematic in cases where there is a protocol-level distinction between parameter-absent and parameter-present-but-zero-length, which is uncommon but can happen. Since OPENSSL_malloc() returns NULL for zero-length allocation requests, make a dummy allocation for this case, to give a signal that the string parameter does exist but has zero length. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #11920)
openssl-machine
pushed a commit
that referenced
this pull request
May 28, 2020
As of the previous commit, when a zero-length (string) parameter is present in the parameters passed to a provider for a given operation, we will produce an object corresponding to that zero-length parameter, indicating to the underlying cryptographic operation that the parameter was passed. However, rsa_cms_decrypt() was relying on the previous behavior, and unconditionally tried to call EVP_PKEY_CTX_set0_rsa_oaep_label() even when the implicit default label was used (and thus the relevant local variable was still NULL). In the new setup that distinguishes present-but-empty and absent more clearly, it is an error to attempt to set a NULL parameter, even if it is zero-length. Exercise more caution when setting parameters, and do not call EVP_PKEY_CTX_set0_rsa_oaep_label() when there is not actually a label provided. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #11920)
|
Merged to master; closing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
This was reported to me as a failure of HKDF with empty IKM (that appears to be a regression from 1.1.1), but also can manifest in other places, such as the RSA OAEP CMS test that I had to provide a fix for.
In general, we have to be able to differentiate between parameter-absent and parameter-present-but-zero-length: some protocols exist that mandate different behavior in these cases. This approach currently feels the most natural to me, though I could be persuaded that an alternate approach is preferred, as I also think that there are aspects of this approach that are ... not exactly pretty.