- Mar 01, 2016
-
-
Andy Polyakov authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 902b30df)
-
Andy Polyakov authored
[Backport from master] CVE-2016-0702 Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Performance penalty varies from platform to platform, and even key length. For rsa2048 sign it was observed to reach almost 10%. CVE-2016-0702 Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Viktor Dukhovni authored
Reviewed-by: Emilia Käsper <emilia@openssl.org>
-
Viktor Dukhovni authored
Reviewed-by: Emilia Käsper <emilia@openssl.org>
-
Viktor Dukhovni authored
SSLv2 is by default disabled at build-time. Builds that are not configured with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of: SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); or SSL_clear_options(ssl, SSL_OP_NO_SSLv2); as appropriate. Even if either of those is used, or the application explicitly uses the version-specific SSLv2_method() or its client or server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available. Mitigation for CVE-2016-0800 Reviewed-by: Emilia Käsper <emilia@openssl.org>
-
- Feb 29, 2016
-
-
Matt Caswell authored
In the BN_hex2bn function the number of hex digits is calculated using an int value |i|. Later |bn_expand| is called with a value of |i * 4|. For large values of |i| this can result in |bn_expand| not allocating any memory because |i * 4| is negative. This leaves ret->d as NULL leading to a subsequent NULL ptr deref. For very large values of |i|, the calculation |i * 4| could be a positive value smaller than |i|. In this case memory is allocated to ret->d, but it is insufficiently sized leading to heap corruption. A similar issue exists in BN_dec2bn. This could have security consequences if BN_hex2bn/BN_dec2bn is ever called by user applications with very large untrusted hex/dec data. This is anticipated to be a rare occurrence. All OpenSSL internal usage of this function uses data that is not expected to be untrusted, e.g. config file data or application command line arguments. If user developed applications generate config file data based on untrusted data then it is possible that this could also lead to security consequences. This is also anticipated to be a rare. Issue reported by Guido Vranken. CVE-2016-0797 Reviewed-by: Andy Polyakov <appro@openssl.org> (cherry picked from commit c1753084)
-
- Feb 27, 2016
-
-
Kurt Roeckx authored
This reverts commit 23a58779 . This broke existing engines that didn't properly implement the sign and verify functions. Reviewed-by: Richard Levitte <levitte@openssl.org> MR: #2077
-
- Feb 25, 2016
-
-
Matt Caswell authored
The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org> (cherry picked from commit 578b956f)
-
Emilia Kasper authored
The SRP user database lookup method SRP_VBASE_get_by_user had confusing memory management semantics; the returned pointer was sometimes newly allocated, and sometimes owned by the callee. The calling code has no way of distinguishing these two cases. Specifically, SRP servers that configure a secret seed to hide valid login information are vulnerable to a memory leak: an attacker connecting with an invalid username can cause a memory leak of around 300 bytes per connection. Servers that do not configure SRP, or configure SRP but do not configure a seed are not vulnerable. In Apache, the seed directive is known as SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user is now disabled even if the user has configured a seed. Applications are advised to migrate to SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong guarantees about the indistinguishability of valid and invalid logins. In particular, computations are currently not carried out in constant time. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- Feb 23, 2016
-
-
FdaSilvaYY authored
Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Kurt Roeckx <kurt@openssl.org> (cherry picked from commit 04f2a0b5)
-
- Feb 19, 2016
-
-
Dr. Stephen Henson authored
Fix double free bug when parsing malformed DSA private keys. Thanks to Adam Langley (Google/BoringSSL) for discovering this bug using libFuzzer. CVE-2016-0705 Reviewed-by: Emilia Käsper <emilia@openssl.org> (cherry picked from commit 6c88c71b)
-
- Feb 12, 2016
-
-
Andy Polyakov authored
It's never problem if CRYPTO_ctr128_encrypt is called from EVP, because buffer in question is always aligned within EVP_CIPHER_CTX structure. RT#4218 Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit 5e4bbeb4)
-
- Feb 11, 2016
-
-
Andy Polyakov authored
Trouble is that LINK variable assignment in make-file interferes with LINK environment variable, which can be used to modify Microsoft's LINK.EXE behaviour. RT#4289 Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit d44bb1c3) Resolved conflicts: util/pl/VC-32.pl (cherry picked from commit 0fffd522)
-
- Feb 10, 2016
-
-
Andy Polyakov authored
Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit 740b2b9a)
-
- Jan 28, 2016
-
-
Kurt Roeckx authored
Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org> (cherry picked from commit 2b0c11a6)
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 41a28cb2)
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
This solves an earlier cherry-pick mistake. Reviewed-by: Matt Caswell <matt@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Update CHANGES and NEWS with details of the issues fixed in the forthcoming release. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Viktor Dukhovni authored
Based on patch by: Nimrod Aviram <nimrod.aviram@gmail.com> CVE-2015-3197 Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Modified version of the commit ffaef3f1 in the master branch by Stephen Henson. This makes the SSL_OP_SINGLE_DH_USE option a no-op and always generates a new DH key for every handshake regardless. This is a follow on from CVE-2016-0701. This branch is not impacted by that CVE because it does not support X9.42 style parameters. It is still possible to generate parameters based on primes that are not "safe", although by default OpenSSL does not do this. The documentation does sign post that using such parameters is unsafe if the private DH key is reused. However to avoid accidental problems or future attacks this commit has been backported to this branch. Issue reported by Antonio Sanso Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
-
- Jan 19, 2016
-
-
Richard Levitte authored
For BSD systems, Configure adds a shared_ldflags including a reference to the Makefile variable LIBRPATH, but since it must be passed down to Makefile.shared, care must be taken so the value of LIBRPATH doesn't get expanded too early, or it ends up giving an empty string. Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit c64879d3)
-
Alessandro Ghedini authored
RT#4080 Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
Prayag Verma authored
Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit 02f70372)
-
- Jan 17, 2016
-
-
Viktor Dukhovni authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- Jan 14, 2016
-
-
Dr. Stephen Henson authored
Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 9aa00b18) Conflicts: apps/x509.c
-
- Jan 10, 2016
-
-
Kurt Roeckx authored
Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>
-
Kurt Roeckx authored
Reviewed-by: Dr. Stephen Henson <steve@openssl.org> (cherry picked from commit 1918e01c)
-
- Jan 05, 2016
-
-
Viktor Dukhovni authored
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
-
- Dec 28, 2015
-
-
Rich Salz authored
Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 41977c53)
-
- Dec 27, 2015
-
-
Matt Caswell authored
Describe the usage of the OCSP callback functions on both the client and the server side. Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit c52c3b5e)
-
Matt Caswell authored
It makes no sense to call the OCSP status callback if we are resuming a session because no certificates will be sent. Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 0ac62399)
-
Matt Caswell authored
If a server sends the status_request extension then it may choose to send the CertificateStatus message. However this is optional. We were treating it as mandatory and the connection was failing. Thanks to BoringSSL for reporting this issue. RT#4120 Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 905943af)
-
- Dec 22, 2015
-
-
David Benjamin authored
Found by clang scan-build. Signed-off-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Richard Levitte <levitte@openssl.org> RT: #4184, MR: #1496 (cherry picked from commit 679d8751)
-
- Dec 20, 2015
-
-
Dr. Stephen Henson authored
Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit 6656ba71)
-
- Dec 19, 2015
-
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 17592f32)
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 6d97060e)
-