- 26 Feb, 2019 5 commits
-
-
Matt Caswell authored
Reviewed-by:Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Follow on from CVE-2019-1559 Reviewed-by: -
Matt Caswell authored
If an application calls SSL_shutdown after a fatal alert has occured and then behaves different based on error codes from that function then the application may be vulnerable to a padding oracle. CVE-2019-1559 Reviewed-by: -
Matt Caswell authored
Reviewed-by:
-
- 25 Feb, 2019 1 commit
-
-
Matt Caswell authored
Thanks to David Benjamin who reported this, performed the analysis and suggested the patch. I have incorporated some of his analysis in the comments below. This issue can cause an out-of-bounds read. It is believed that this was not reachable until the recent "fixed top" changes. Analysis has so far only identified one code path that can encounter this - although it is possible that others may be found. The one code path only impacts 1.0.2 in certain builds. The fuzzer found a path in RSA where iqmp is too large. If the input is all zeros, the RSA CRT logic will multiply a padded zero by iqmp. Two mitigating factors: - Private keys which trip this are invalid (iqmp is not reduced mod p). Only systems which take untrusted private keys care. - In OpenSSL 1.1.x, there is a check which rejects the oversize iqmp, so the bug is only reproducible in 1.0.2 so far. Fortunately, the bug appears to be relatively harmless. The consequences of bn_cmp_word's misbehavior are: - OpenSSL may crash if the buffers are page-aligned and the previous page is non-existent. - OpenSSL will incorrectly treat two BN_ULONG buffers as not equal when they are equal. - Side channel concerns. The first is indeed a concern and is a DoS bug. The second is fine in this context. bn_cmp_word and bn_cmp_part_words are used to compute abs(a0 - a1) in Karatsuba. If a0 = a1, it does not matter whether we use a0 - a1 or a1 - a0. The third would be worth thinking about, but it is overshadowed by the entire Karatsuba implementation not being constant time. Due to the difficulty of tripping this and the low impact no CVE is felt necessary for this issue. Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8326) (cherry picked from commit 576129cd)
-
- 20 Feb, 2019 2 commits
-
-
Nicola Tuveri authored
(cherry picked from commit c8147d37 ) Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8295)
-
Nicola Tuveri authored
This commit adds a simple unit test to make sure that the constant-time flag does not "leak" among BN_CTX frames: - test_ctx_consttime_flag() initializes (and later frees before returning) a BN_CTX object, then it calls in sequence test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same BN_CTX object. - test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame before ending it. - test_ctx_check_ct_flag() then starts a new frame and gets a number of BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new frame should have BN_FLG_CONSTTIME set. In actual BN_CTX usage inside libcrypto the leak could happen at any depth level in the BN_CTX stack, with varying results depending on the patterns of sibling trees of nested function calls sharing the same BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the called BN_* functions. This simple unit test abstracts away this complexity and verifies that the leak does not happen between two sibling functions sharing the same BN_CTX object at the same level of nesting. (manually cherry picked from commit fe16ae5f ) Reviewed-by:
-
- 18 Feb, 2019 1 commit
-
-
Richard Levitte authored
Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8273)
-
- 15 Feb, 2019 1 commit
-
-
Corinna Vinschen authored
Cygwin binaries should not enforce text mode these days, just use text mode if the underlying mount point requests it CLA: trivial Signed-off-by:
Corinna Vinschen <vinschen@redhat.com> Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
-
- 15 Jan, 2019 3 commits
-
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
- 03 Jan, 2019 1 commit
-
-
Matt Caswell authored
Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> (Merged from https://github.com/openssl/openssl/pull/7974)
-
- 15 Dec, 2018 1 commit
-
-
Richard Levitte authored
Fixes #7903 Reviewed-by:
-
- 12 Dec, 2018 2 commits
-
-
Dr. Matthias St. Pierre authored
Fixes #7883 Reviewed-by:
-
Tobias Stoeckmann authored
There was a trailing :w at a line, which didn't make sense in context of the sentence/styling. Removed it, because I think it's a leftover vi command. CLA: trivial Signed-off-by:
Tobias Stoeckmann <tobias@stoeckmann.org> Reviewed-by:
-
- 07 Dec, 2018 1 commit
-
-
Richard Levitte authored
It turns out that the strictness that was implemented in EVP_PKEY_asn1_new() (see Github openssl/openssl#6880) was badly placed for some usages, and that it's better to do this check only when the method is getting registered. Fixes #7758 Reviewed-by:
-
- 06 Dec, 2018 5 commits
-
-
Andy Polyakov authored
Copy of RSA_padding_check_PKCS1_type_2 with a twist that rejects padding if nul delimiter is preceded by 8 consecutive 0x03 bytes. Reviewed-by:
-
Andy Polyakov authored
And make RSAErr call unconditional. Reviewed-by:
-
Andy Polyakov authored
And make RSAErr call unconditional. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Expected usage pattern is to unconditionally set error and then wipe it if there was no actual error. Reviewed-by:
-
- 03 Dec, 2018 1 commit
-
-
Richard Levitte authored
Reviewed-by:
-
- 24 Nov, 2018 2 commits
-
-
David Woodhouse authored
If the private key says it can only support one specific digest, then don't ask it to perform a different one. Fixes: #7348 (cherry picked from commit 2d263a4a and reworked for 1.0.2) Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/7610)
-
David Woodhouse authored
ASN1_PKEY_CTRL_DEFAULT_MD_NID is documented to return 2 for a mandatory digest algorithm, when the key can't support any others. That isn't true here, so return 1 instead. Partially fixes #7348 (cherry picked from commit eb7eb137 ) Reviewed-by:
-
- 23 Nov, 2018 1 commit
-
-
Andy Polyakov authored
Blinding is performed more efficiently and securely if MONT_CTX for public modulus is available by the time blinding parameter are instantiated. So make sure it's the case. Reviewed-by:
-
- 22 Nov, 2018 1 commit
-
-
Richard Levitte authored
A lacking DCL variable to indicate where it's located was missing. Reviewed-by:
-
- 20 Nov, 2018 6 commits
-
-
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
- 14 Nov, 2018 1 commit
-
-
Vitezslav Cizek authored
dsa_builtin_paramgen2 expects the L parameter to be greater than N, otherwise the generation will get stuck in an infinite loop. Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
- 12 Nov, 2018 1 commit
-
-
Billy Brumley authored
Reviewed-by:
-
- 09 Nov, 2018 1 commit
-
-
Dr. Matthias St. Pierre authored
Fixes #3302 Reviewed-by:
-
- 02 Nov, 2018 1 commit
-
-
Matt Caswell authored
Since 3884b47b we may attempt to buffer a record from the next epoch that has already been buffered. Prior to that this never occurred. We simply ignore a failure to buffer a duplicated record. Fixes #6902 Reviewed-by:
-
- 01 Nov, 2018 1 commit
-
-
Pauli authored
Reviewed-by:
-
- 29 Oct, 2018 1 commit
-
-
Pauli authored
There is a side channel attack against the division used to calculate one of the modulo inverses in the DSA algorithm. This change takes advantage of the primality of the modulo and Fermat's little theorem to calculate the inverse without leaking information. Thanks to Samuel Weiser for finding and reporting this. Reviewed-by:
-
