This commit addresses a potential side-channel vulnerability in the
internals of some elliptic curve low level operations.
The side-channel leakage appears to be tiny, so the severity of this
issue is rather low.
The issue was reported by David Schrammel and Samuel Weiser.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/9239)
(cherry picked from commit 3cb914c463ed1c9e32cfb773d816139a61b6ad5f)
The New Year has caused various files to appear out of date to "make
update". This causes Travis to fail. Therefore we update those files.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10739)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/10676)
(cherry picked from commit 9d079f2744b9b624c6fe75f95fc0f766ef88ffcf)
We store a secondary frame pointer info for the debugger
in the red zone. This fixes a crash in the unwinder when
this function is interrupted.
Additionally the missing cfi function annotation is added
to aesni_cbc_sha256_enc_shaext.
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10674)
(cherry picked from commit 665de4d48aef2507022a7d74f5c7f6e339d5e6bc)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/10642)
(cherry picked from commit 6b913be708f98b1d971586d38e608218ee6de6fa)
While stack unwinding works with gdb here, the
function _Unwind_Backtrace gives up when something outside
.cfi_startproc/.cfi_endproc is found in the call stack, like
OPENSSL_cleanse, OPENSSL_atomic_add, OPENSSL_rdtsc, CRYPTO_memcmp
and other trivial functions which don't save anything in the stack.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/10635)
(cherry picked from commit 8913378a552e470c66277c47b19699f20b84aa3b)
This is a missing accessor in order to obtain PSS parameters from an
RSA key, which should also be available in 1.1.1.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10568)
OpenSSL supports both PKCS#3 and X9.42 DH keys. By default we use PKCS#3
keys. The function `EVP_PKEY_set1_DH` was assuming that the supplied DH
key was a PKCS#3 key. It should detect what type of key it is and assign
the correct type as appropriate.
Fixes#10592
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10593)
(cherry picked from commit 32c869ffaba67822602ea9fec611272ff8e8db58)
RAND_get_rand_method() can return a NULL method pointer in the case of a
malloc failure, so don't dereference it without a check.
Reported-by: Zu-Ming Jiang (detected by FIFUZZ)
Fixes#10480
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10490)
We have always a carry in %rcx or %rbx in range 0..2
from the previous stage, that is added to the result
of the 64-bit square, but the low nibble of any square
can only be 0, 1, 4, 9.
Therefore one "adcq $0, %rdx" can be removed.
Likewise in the ADX code we can remove one
"adcx %rbp, $out" since %rbp is always 0, and carry is
also zero, therefore that is a no-op.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10575)
There is an overflow bug in the x64_64 Montgomery squaring procedure used in
exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a
result of this defect would be very difficult to perform and are not believed
likely. Attacks against DH512 are considered just feasible. However, for an
attack the target would have to re-use the DH512 private key, which is not
recommended anyway. Also applications directly using the low level API
BN_mod_exp may be affected if they use BN_FLG_CONSTTIME.
CVE-2019-1551
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/10575)
Even with custom ciphers, the combination in == NULL && inl == 0
should not be passed down to the backend cipher function. The reason
is that these are the values passed by EVP_*Final, and some of the
backend cipher functions do check for these to see if a "final" call
is made.
An exception is made for CCM mode which has special handling for the case
where inl == 0: this may mean the total plaintext or ciphertext length is 0.
This is based on an original commit by Richard Levitte.
Fixes#8675
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9057)
We used EVP_EncryptInit_ex() to initialise, but EVP_DecryptUpdate()
and EVP_DecryptFinal_ex() to actually perform encryption. This worked
long ago, when the Encrypt and Decrypt variants were the same, but
doesn't now (actually haven't for a very long time).
This shows how seldom PVK is actually used.
Fixes#9338
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10521)
Check for NULL and return error if so.
This can possibly be called from apps/ca.c with a NULL argument.
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/10474)
(cherry picked from commit ab5c77b4766e0992751d86560193ca42b49cf316)
Add NULL check for return from pkey_asn1_meths.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10473)
(cherry picked from commit 9bada854de16bcc1a9dc199b4b352b19ab6897fc)
Verifications are public, there is no need to clear the used storage before
freeing it.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10475)
(cherry picked from commit cff7d199e0dc51ae939de5fb7702aab2a9ef30fc)
We store a secondary frame pointer info for the debugger
in the red zone.
Fixes#8853
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9624)
(cherry picked from commit 9ce91035bcf7d74fe15c94650f3bc1f89b7c0f07)
In addition to 67c81ec3 which introduced this behavior in CCM mode
docs but only implemented it for AES-CCM.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10331)
(cherry picked from commit f7382fbbd846dd3bdea6b8c03b6af22faf0ab94f)
Conflicts:
test/recipes/30-test_evp_data/evpciph.txt
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10454)
(cherry picked from commit 97a986f78289fef71bf8778dc4763458e983750c)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10388)
(cherry picked from commit 2555285fa5e4248ad4a5a0bc14ae4606443856c2)
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10417)
(cherry picked from commit c31950b964a2f3f7b9e6ad98076954178ee1e77d)
EC_POINT_bn2point() rejected BIGNUMs with a zero value.
This behavior indirectly caused failures when converting a point
at infinity through EC_POINT_point2hex() and then back to a point with
EC_POINT_hex2point().
With this change such BIGNUMs are treated like any other and exported to
an octet buffer filled with zero.
It is then EC_POINT_oct2point() (either the default implementation or
the custom one in group->meth->oct2point) to determine if such encoding
maps to a valid point (generally the point at infinity is encoded as
0x00).
Fixes#10258
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10329)
(cherry picked from commit d47c10875656790d146f62ac3c437db54c58dbf7)
'__builtin_strncpy' offset [275, 4095] from the object at
'direntry' is out of the bounds of referenced subobject 'd_name'
with type 'char[256]' at offset 19
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10343)
(cherry picked from commit db5cf86535b305378308c58c52596994e1ece1e6)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10361)
(cherry picked from commit d1c1fb2d41a627293483d832aaffcb6eca9075f9)
If no connection could be made, addr_iter will eventually end up being
NULL, and if the user didn't check the returned error value, the
BIO_CONN_S_CONNECT code will be performed again and will crash.
So instead, we add a state BIO_CONN_S_CONNECT_ERROR that we enter into
when we run out of addresses to try. That state will just simply say
"error" back, until the user does something better with the BIO, such
as free it or reset it.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10333)
i2v_GENERAL_NAMES call i2v_GENERAL_NAME repeatedly as required. Each
time i2v_GENERAL_NAME gets called it allocates adds data to the passed in
stack and then returns a pointer to the stack, or NULL on failure. If
the passed in stack is itself NULL then it allocates one.
i2v_GENERAL_NAMES was not correctly handling the case where a NULL gets
returned from i2v_GENERAL_NAME. If a stack had already been allocated then
it just leaked it.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10300)
(cherry picked from commit 45b244620a74248b46ebe1c85e86437b9641447a)
clang imposes some restrictions on the assembler code that
gcc does not.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10330)
(cherry picked from commit 6f93f06135cbbd36c3fe98d63717e8303a5d559b)
Conflicts:
crypto/perlasm/s390x.pm (non-existant)
crypto/s390xcpuid.pl (code to be changed non-existant)
This system services is based on FreeBSD 12's getentropy(), and is
therefore treated the same way as getentropy() with regards to amount
of entropy bits per data bit.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8926)
(cherry picked from commit 8b9896eb293a0861f0b8c191b7a278f176b729e6)
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10311)
(cherry picked from commit 351ba5bd27645d5b5a2bc643b2709bd30bcdf09c)
Free dukm in error handling of dh_cms_encrypt()
Fixes#10294
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
(Merged from https://github.com/openssl/openssl/pull/10310)
(cherry picked from commit 6624e1f7b6a397948561e9cc2774f0c8af1d2c79)
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10209)
(cherry picked from commit 305bf9c8668aff78e668131061f4eb088457be5f)
This was fixed in #8321 right after the 1.1.1 was released but never
back ported to 1.1.1. Now fix it.
Issue reported from lua-openssl project.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10278)
RSA-PSS keys use the same internal structure as RSA keys but do not
allow accessing it through EVP_PKEY_get0_RSA. This commit changes that
behavior.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10217)
(cherry picked from commit 465a58b117d5a85623f3998d6fbf2fe8712a5604)
PR https://github.com/openssl/openssl/pull/10122 introduced changes to
the BN_gcd function and the control logic inside it accessed `g->d[0]`
irrespective of `g->top`.
When BN_add is called, in case the result is zero, `BN_zero` is called.
The latter behaves differently depending on the API compatibility level
flag: normally `g->d[0]` is cleared but in `no-deprecated` builds only
`g->top` is set to zero.
This commit uses bitwise logic to ensure that `g` is treated as zero if
`g->top` is zero, irrespective of `g->d[0]`.
Co-authored-by: Nicola Tuveri <nic.tuv@gmail.com>
(cherry picked from commit 8aca4bfe8213402c80abc06fe25121461f79128d)
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10232)
This commit replaces the current `BN_gcd` function with a constant-time
GCD implementation.
(cherry picked from commit f3c4adfc7eb13e9eff514039b4c60b457bdba433)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10122)
This commit aims at refactoring the `BN_rshift` by making it a wrapper
around `bn_rshift_fixed_top`, in order to match the current design of
`BN_lshift`, as suggested in the discussion at
https://github.com/openssl/openssl/pull/10122#discussion_r332474277 .
As described in the code, by refactoring this function, `BN_rshift`
provides a constant-time behavior for sufficiently[!] zero-padded inputs
under the following assumptions: `|n < BN_BITS2|` or `|n / BN_BITS2|`
being non-secret.
Notice that `BN_rshift` returns a canonical representation of the
BIGNUM, if a `fixed_top` representation is required, the caller should
call `bn_rshift_fixed_top` instead.
(cherry picked from commit 8eba6de59e2b06f23c214344423a5a618d1c9ffd)
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10196)
