- Jun 07, 2019
-
-
Acheev Bhagat authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/9101)
-
- May 28, 2019
-
-
Richard Levitte authored
Reviewed-by:Matt Caswell <matt@openssl.org>
-
Richard Levitte authored
Reviewed-by: -
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
- May 21, 2019
-
-
Kurt Roeckx authored
Fixes: #8737 Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
- Apr 25, 2019
-
-
Emilia Kasper authored
This is a backport of commit 1e2012b7 to 1.0.2. This hardening change was made to 1.1.0 but was not backported to 1.0.2. Recent CVEs in user applications have shown this additional hardening in 1.0.2 would be beneficial. E.g. see the patch for CVE-2019-9498 https://w1.fi/security/2019-4/0011-EAP-pwd-server-Verify-received-scalar-and-element.patch and CVE-2019-9499 https://w1.fi/security/2019-4/0013-EAP-pwd-client-Verify-received-scalar-and-element.patch The original commit had this description: We already test in EC_POINT_oct2point that points are on the curve. To be on the safe side, move this check to EC_POINT_set_affine_coordinates_* so as to also check point coordinates received through some other method. We do not check projective coordinates, though, as - it's unlikely that applications would be receiving this primarily internal representation from untrusted sources, and - it's possible that the projective setters are used in a setting where performance matters. Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
-
- Apr 16, 2019
-
-
Dr. Matthias St. Pierre authored
Fixes #2490 Fixes #8711 In commit 6db8e3bd , support for Android Arm 64-bit was added to the OpenSSL FIPS Object Module. For some reason, the corresponding target 'android64-aarch64' was missing OpenSSL 1.0.2, whence it could not be built with FIPS support on Android Arm 64-bit. This commit adds the missing target. Reviewed-by:
-
- Mar 30, 2019
-
-
Shane Lontis authored
Reviewed-by:
-
- Mar 22, 2019
-
-
Bernd Edlinger authored
constant time with a memory access pattern that does not depend on secret information. [extended tests] Reviewed-by:
-
Bernd Edlinger authored
[extended tests] Reviewed-by:
-
- Mar 18, 2019
-
-
Bernd Edlinger authored
The secret point R can be recovered from S using the equation R = S - P. The X and Z coordinates should be sufficient for that. Reviewed-by:
-
- Mar 17, 2019
-
-
Bernd Edlinger authored
Reviewed-by:
-
- Mar 07, 2019
-
-
Bernd Edlinger authored
Backported from d7f5e5ae Fixes #8364 and #8357 Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/8438)
-
Matt Caswell authored
The function felem_diff_128_64 in ecp_nistp521.c substracts the number |in| from |out| mod p. In order to avoid underflow it first adds 32p mod p (which is equivalent to 0 mod p) to |out|. The comments and variable naming suggest that the original author intended to add 64p mod p. In fact it has been shown that with certain unusual co-ordinates it is possible to cause an underflow in this function when only adding 32p mod p while performing a point double operation. By changing this to 64p mod p the underflow is avoided. It turns out to be quite difficult to construct points that satisfy the underflow criteria although this has been done and the underflow demonstrated. However none of these points are actually on the curve. Finding points that satisfy the underflow criteria and are also *on* the curve is considered significantly more difficult. For this reason we do not believe that this issue is currently practically exploitable and therefore no CVE has been assigned. This only impacts builds using the enable-ec_nistp_64_gcc_128 Configure option. With thanks to Bo-Yin Yang, Billy Brumley and Dr Liu for their significant help in investigating this issue. Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/8405) (cherry picked from commit 13fbce17)
-
- Feb 26, 2019
-
-
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
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:
-
- Feb 25, 2019
-
-
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:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8326) (cherry picked from commit 576129cd)
-
- Feb 20, 2019
-
-
Nicola Tuveri authored
(cherry picked from commit c8147d37 ) Reviewed-by:
-
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:
-
- Feb 18, 2019
-
-
Richard Levitte authored
Reviewed-by:
-
- Feb 15, 2019
-
-
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:
-
- Jan 15, 2019
-
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
- Jan 03, 2019
-
-
Matt Caswell authored
Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> (Merged from https://github.com/openssl/openssl/pull/7974)
-
- Dec 15, 2018
-
-
Richard Levitte authored
Fixes #7903 Reviewed-by:
-
- Dec 12, 2018
-
-
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:
-
- Dec 07, 2018
-
-
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:
-
- Dec 06, 2018
-
-
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:
-
- Dec 03, 2018
-
-
Richard Levitte authored
Reviewed-by:
-
