- 28 May, 2019 2 commits
-
-
Richard Levitte authored
Reviewed-by:Matt Caswell <matt@openssl.org>
-
Richard Levitte authored
Reviewed-by:
-
- 27 May, 2019 1 commit
-
-
Richard Levitte authored
Reviewed-by:
-
- 21 May, 2019 1 commit
-
-
Kurt Roeckx authored
Fixes: #8737 Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
Richard Levitte <levitte@openssl.org> GH: #8741 (cherry picked from commit 70b0b977)
-
- 30 Mar, 2019 1 commit
-
-
Shane Lontis authored
Reviewed-by:
-
- 22 Mar, 2019 2 commits
-
-
Bernd Edlinger authored
constant time with a memory access pattern that does not depend on secret information. [extended tests] Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8543) (cherry picked from commit 9c0cf214)
-
Bernd Edlinger authored
[extended tests] Reviewed-by:
-
- 18 Mar, 2019 2 commits
-
-
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:
-
Bernd Edlinger authored
Reviewed-by:
-
- 07 Mar, 2019 2 commits
-
-
Bernd Edlinger authored
Fixes #8364 and #8357 Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/8365) (cherry picked from commit d7f5e5ae)
-
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)
-
- 06 Mar, 2019 2 commits
-
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. CVE-2019-1543 Fixes #8345 Reviewed-by:
-
- 26 Feb, 2019 2 commits
-
-
Matt Caswell authored
Follow on from CVE-2019-1559 Reviewed-by: -
Matt Caswell authored
1.1.0 is not impacted by CVE-2019-1559, but this commit is a follow on from that. That CVE was a result of applications calling SSL_shutdown after a fatal alert has occurred. By chance 1.1.0 is not vulnerable to that issue, but this change is additional hardening to prevent other similar issues. 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:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8326) (cherry picked from commit 576129cd)
-
- 24 Feb, 2019 1 commit
-
-
Jeff Mahoney authored
The backport of master commit 5c6a69f5 (apps/speed: fix possible OOB access in some EC arrays) as 1.1.0 commit 4e079413 introduced a regression. The ecdh_choices array is iterated using an element count but is NULL terminated. This means that running 'openssl speed somealgo' will result in a segfault when opt_found hits the NULL entry. Fixes #8243 CLA: trivial Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> Reviewed-by:
-
- 21 Feb, 2019 2 commits
-
-
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. The process is run twice, once with a "normal" BN_CTX_new() object, then with a BN_CTX_secure_new() one. - 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:
-
- 20 Feb, 2019 2 commits
-
-
Nicola Tuveri authored
This is a rewrite of commit 8f58ede0 for the 1.1.0-stable branch. Co-authored-by:
Billy Brumley <bbrumley@gmail.com> Reviewed-by:
-
Billy Brumley authored
This commit adds a dedicated function in `EC_METHOD` to access a modular field inversion implementation suitable for the specifics of the implemented curve, featuring SCA countermeasures. The new pointer is defined as: `int (*field_inv)(const EC_GROUP*, BIGNUM *r, const BIGNUM *a, BN_CTX*)` and computes the multiplicative inverse of `a` in the underlying field, storing the result in `r`. Three implementations are included, each including specific SCA countermeasures: - `ec_GFp_simple_field_inv()`, featuring SCA hardening through blinding. - `ec_GFp_mont_field_inv()`, featuring SCA hardening through Fermat's Little Theorem (FLT) inversion. - `ec_GF2m_simple_field_inv()`, that uses `BN_GF2m_mod_inv()` which already features SCA hardening through blinding. From a security point of view, this also helps addressing a leakage previously affecting conversions from projective to affine coordinates. This commit also adds a new error reason code (i.e., `EC_R_CANNOT_INVERT`) to improve consistency between the three implementations as all of them could fail for the same reason but through different code paths resulting in inconsistent error stack states. Co-authored-by:
-
- 18 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 Signed-off-by:
Corinna Vinschen <vinschen@redhat.com> Reviewed-by:
-
- 11 Feb, 2019 1 commit
-
-
Richard Levitte authored
bn2crparam() incorrectly delivered a big endian byte string to cryptodev. Using BN_bn2lebinpad() instead of BN_bn2bin() fixes this. crparam2bn() had a hack that avoided this issue in the other direction, but allocated an intermediary chunk of memory to get correct endianness. Using BN_lebin2bn() avoids this allocation. Fixes #8202 Reviewed-by:
-
- 31 Jan, 2019 1 commit
-
-
Bernd Edlinger authored
If the second PUBKEY is malformed there is use after free. Reviewed-by:
-
- 12 Dec, 2018 1 commit
-
-
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:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
- 08 Dec, 2018 6 commits
-
-
Andy Polyakov authored
Reviewed-by:
-
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:
-
- 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:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7847) (cherry picked from commit a8600316)
-
- 24 Nov, 2018 5 commits
-
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
When creating a tarball, it's pointless to include scripts that assume a git workspace. Reviewed-by:
-
Richard Levitte authored
Also adds missing copyright boilerplate to util/mktar.sh Reviewed-by:
-
- 23 Nov, 2018 3 commits
-
-
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:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Since recently, OpenSSL tarballs are produced with 'make tar' rather than 'make dist', as the latter has turned out to be more troublesome than useful. The next step to look at is why we would need to configure at all to produce a Makefile just to produce a tarball. After all, the tarball should now only contain source files that are present even without configuring. Furthermore, the current method for producing tarballs is a bit complex, and can be greatly simplified with the right tools. Since we have everything versioned with git, we might as well use the tool that comes with it. Added: util/mktar.sh, a simple script to produce OpenSSL tarballs. It takes the options --name to modify the prefix of the distribution, and --tarfile tp modify the tarball file name specifically. This also adds a few entries in .gitattributes to specify files that should never end up in a distribution tarball. Reviewed-by:
-
