- Nov 12, 2017
-
-
Josh Soref authored
Around 138 distinct errors found and fixed; thanks! Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3459)
-
- Nov 11, 2017
-
-
Long Qin authored
* addressing", Proc. 6th Conference on Very Large Databases: 212–223 ^ The EN DASH ('–') in this line is one UTF-8 character (hex: e2 80 93). Under some code page setting (e.g. 936), Visual Studio may report C4819 warning: The file contains a character that cannot be represented in the current code page. Replace this character with the ASCII char '-' (Hex Code: 2D). Reviewed-by:Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4691)
-
- Nov 10, 2017
-
-
FdaSilvaYY authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4677)
-
- Nov 08, 2017
-
-
Andy Polyakov authored
Reviewed-by: -
Rich Salz authored
Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/4703)
-
Rich Salz authored
Reviewed-by:
-
- Nov 07, 2017
-
-
FdaSilvaYY authored
Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4457)
-
FdaSilvaYY authored
Reviewed-by:
-
Matt Caswell authored
There were 4 macros in ocsp.h that have not worked since 1.1.0 because they attempt to access the internals of an opaque structure. For OCSP_REQUEST_sign() applications should use OCSP_request_sign() instead. For OCSP_BASICRESP_sign() applications should use OCSP_basic_sign() instead. For OCSP_REQUEST_verify() applications should use OCSP_request_verify() instead. For OCSP_BASICRESP_verify() applications should use OCSP_basic_verify() instead. Reviewed-by:
-
- Nov 05, 2017
-
-
Ronald Tse authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
-
Jack Lloyd authored
SM3 is a secure hash function which is part of the Chinese "Commercial Cryptography" suite of algorithms which use is required for certain commercial applications in China. Reviewed-by:
-
FdaSilvaYY authored
Based on patch from Tomasz Moń: https://groups.google.com/forum/#!topic/mailing.openssl.dev/fQxXvCg1uQY Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
-
Andy Polyakov authored
It's not clear if it's a feature or bug, but binutils-2.29[.1] interprets 'adr' instruction with Thumb2 code reference differently, in a way that affects calculation of addresses of constants' tables. Reviewed-by:
-
- Nov 03, 2017
-
-
Pavel Kopyl authored
CLA: trivial Reviewed-by:
-
Pavel Kopyl authored
CLA: trivial Reviewed-by:
-
Pavel Kopyl authored
CLA: trivial Reviewed-by:
-
- Nov 02, 2017
-
-
Andy Polyakov authored
Credit to OSS-Fuzz for finding this. CVE-2017-3736 Reviewed-by:
-
- Nov 01, 2017
-
-
Pauli authored
information about the length of the scalar used in ECDSA operations from a large number (2^32) of signatures. This doesn't rate as a CVE because: * For the non-constant time code, there are easier ways to extract more information. * For the constant time code, it requires a significant number of signatures to leak a small amount of information. Thanks to Neals Fournaise, Eliane Jaulmes and Jean-Rene Reinhard for reporting this issue. Reviewed-by:
-
Pauli authored
information about the length of a value used in DSA operations from a large number of signatures. This doesn't rate as a CVE because: * For the non-constant time code, there are easier ways to extract more information. * For the constant time code, it requires a significant number of signatures to leak a small amount of information. Thanks to Neals Fournaise, Eliane Jaulmes and Jean-Rene Reinhard for reporting this issue. Reviewed-by:
-
- Oct 31, 2017
-
-
Ronald Tse authored
Reviewed-by:
-
- Oct 30, 2017
-
-
Kurt Roeckx authored
This restores the 1.0.2 behaviour Reviewed-by:
Benjamin Kaduk <bkaduk@akamai.com> GH: #4613
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
No two public key ASN.1 methods with the same pkey_id can be registered at the same time. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Benjamin Kaduk authored
If the list of fds contains only (one or more) entries marked as deleted prior to the entry currently being deleted, and the entry currently being deleted was only just added, the 'prev' pointer would never be updated from its initial NULL value, and we would dereference NULL while trying to remove the entry from the linked list. Reported by Coverity. Reviewed-by:
-
Patrick Steuer authored
Extend the s390x capability vector to store the longer facility list available from z13 onwards. The bits indicating the vector extensions are set to zero, if the kernel does not enable the vector facility. Also add capability bits returned by the crypto instructions' query functions. Signed-off-by:
Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by:
-
- Oct 26, 2017
-
-
Paul Yang authored
Use the newly introduced sk_TYPE_new_reserve API to simplify the reservation of stack as creating it. Reviewed-by:
-
Matt Caswell authored
The functions strcasecmp() and strncasecmp() will use locale specific rules when performing comparison. This could cause some problems in certain locales. For example in the Turkish locale an 'I' character is not the uppercase version of 'i'. However IA5 strings should not use locale specific rules, i.e. for an IA5 string 'I' is uppercase 'i' even if using the Turkish locale. This fixes a bug in name constraints checking reported by Thomas Pornin (NCCGroup). This is not considered a security issue because it would require both a Turkish locale (or other locale with similar issues) and malfeasance by a trusted name-constrained CA for a certificate to pass name constraints in error. The constraints also have to be for excluded sub-trees which are extremely rare. Failure to match permitted subtrees is a bug, not a vulnerability. Reviewed-by:
-
- Oct 25, 2017
-
-
Paul Yang authored
This is a combination of sk_new and sk_reserve, to make it more convenient to allocate a new stack with reserved memory and comaprison function (if any). Reviewed-by:
-
- Oct 24, 2017
-
-
Richard Levitte authored
asn1_item_embed_free() will try unlocking and fail in this case, and since the new item was just allocated on the heap, free it directly with OPENSSL_free() instead. Reviewed-by:
-
Richard Levitte authored
The previous change with this intention didn't quite do it. An embedded item must not be freed itself, but might potentially contain non-embedded elements, which must be freed. So instead of calling ASN1_item_ex_free(), where we can't pass the embed flag, we call asn1_item_embed_free() directly. This changes asn1_item_embed_free() from being a static function to being a private non-static function. Reviewed-by:
-
Matt Caswell authored
The lhash expand() function can fail if realloc fails. The previous implementation made changes to the structure and then attempted to do a realloc. If the realloc failed then it attempted to undo the changes it had just made. Unfortunately changes to lh->p were not undone correctly, ultimately causing subsequent expand() calls to increment num_nodes to a value higher than num_alloc_nodes, which can cause out-of-bounds reads/ writes. This is not considered a security issue because an attacker cannot cause realloc to fail. This commit moves the realloc call to near the beginning of the function before any other changes are made to the lhash structure. That way if a failure occurs we can immediately fail without having to undo anything. Thanks to Pavel Kopyl (Samsung) for reporting this issue. Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4550)
-
- Oct 23, 2017
-
-
Xiangyu Bu authored
CLA: trivial Reviewed-by:
-
Richard Levitte authored
An embedded item wasn't allocated separately on the heap, so don't free it as if it was. Issue discovered by Pavel Kopyl Reviewed-by:
-
Matt Caswell authored
The function BN_security_bits() uses the values from SP800-57 to assign security bit values for different FF key sizes. However the value for 192 security bits is wrong. SP800-57 has it as 7680 but the code had it as 7690. Reviewed-by:
-
- Oct 21, 2017
-
-
KaoruToda authored
Reviewed-by:
-
- Oct 18, 2017
-
-
KaoruToda authored
Since return is inconsistent, I removed unnecessary parentheses and unified them. Reviewed-by:
-
Benjamin Kaduk authored
The drbg's lock must be held across calls to RAND_DRBG_generate() to prevent simultaneous modification of internal state. This was observed in practice with simultaneous SSL_new() calls attempting to seed the (separate) per-SSL RAND_DRBG instances from the global rand_drbg instance; this eventually led to simultaneous calls to ctr_BCC_update() attempting to increment drbg->bltmp_pos for their respective partial final block, violating the invariant that bltmp_pos < 16. The AES operations performed in ctr_BCC_blocks() makes the race window quite easy to trigger. A value of bltmp_pos greater than 16 induces catastrophic failure in ctr_BCC_final(), with subtraction overflowing and leading to an attempt to memset() to zero a very large range, which eventually reaches an unmapped page and segfaults. Provide the needed locking in get_entropy_from_parent(), as well as fixing a similar issue in RAND_priv_bytes(). There is also an unlocked call to RAND_DRBG_generate() in ssl_randbytes(), but the requisite serialization is already guaranteed by the requirements on the application's usage of SSL objects, and no further locking is needed for correct behavior. In that case, leave a comment noting the apparent discrepancy and the reason for its safety (at present). Reviewed-by:
-
Dr. Matthias St. Pierre authored
The DRBG_RESEED state plays an analogue role to the |reseed_required_flag| in Appendix B.3.4 of [NIST SP 800-90A Rev. 1]. The latter is a local variable, the scope of which is limited to the RAND_DRBG_generate() function. Hence there is no need for a DRBG_RESEED state outside of the generate function. This state was removed and replaced by a local variable |reseed_required|. Reviewed-by:
-
Dr. Matthias St. Pierre authored
Reseeding is handled very differently by the classic RAND_METHOD API and the new RAND_DRBG api. These differences led to some problems when the new RAND_DRBG was made the default OpenSSL RNG. In particular, RAND_add() did not work as expected anymore. These issues are discussed on the thread '[openssl-dev] Plea for a new public OpenSSL RNG API' and in Pull Request #4328. This commit fixes the mentioned issues, introducing the following changes: - Replace the fixed size RAND_BYTES_BUFFER by a new RAND_POOL API which facilitates collecting entropy by the get_entropy() callback. - Don't use RAND_poll()/RAND_add() for collecting entropy from the get_entropy() callback anymore. Instead, replace RAND_poll() by RAND_POOL_acquire_entropy(). - Add a new function rand_drbg_restart() which tries to get the DRBG in an instantiated state by all means, regardless of the current state (uninstantiated, error, ...) the DRBG is in. If the caller provides entropy or additional input, it will be used for reseeding. - Restore the original documented behaviour of RAND_add() and RAND_poll() (namely to reseed the DRBG immediately) by a new implementation based on rand_drbg_restart(). - Add automatic error recovery from temporary failures of the entropy source to RAND_DRBG_generate() using the rand_drbg_restart() function. Reviewed-by:
-
