- Mar 08, 2016
-
-
Viktor Dukhovni authored
This improves ABI compatibility when symbol resolution is not lazy. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
- Mar 07, 2016
-
-
Kurt Roeckx authored
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
-
Dr. Stephen Henson authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Andy Polyakov authored
Some OSes, *cough*-dows, insist on stack being "wired" to physical memory in strictly sequential manner, i.e. if stack allocation spans two pages, then reference to farmost one can be punishable by SEGV. But page walking can do good even on other OSes, because it guarantees that villain thread hits the guard page before it can make damage to innocent one... Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit adc4f1fc)
-
Andy Polyakov authored
Not all assemblers of "gas" flavour handle binary constants, e.g. seasoned MacOS Xcode doesn't, so give them a hand. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 6e42e3ff)
-
- Mar 04, 2016
-
-
Dr. Stephen Henson authored
PVK files with abnormally large length or salt fields can cause an integer overflow which can result in an OOB read and heap corruption. However this is an rarely used format and private key files do not normally come from untrusted sources the security implications not significant. Fix by limiting PVK length field to 100K and salt to 10K: these should be more than enough to cover any files encountered in practice. Issue reported by Guido Vranken. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 5f57abe2)
-
- Mar 01, 2016
-
-
Eric S. Raymond authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Update mk1mf.pl to properly handle no-weak-ssl-ciphers Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
and reorganize/harmonize post-conditions. Additional hardening following on from CVE-2016-0702 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from master)
-
Andy Polyakov authored
At the same time remove miniscule bias in final subtraction. Performance penalty varies from platform to platform, and even with key length. For rsa2048 sign it was observed to be 4% for Sandy Bridge and 7% on Broadwell. CVE-2016-0702 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from master)
-
Andy Polyakov authored
Performance penalty is 2%. CVE-2016-0702 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from master)
-
Andy Polyakov authored
Performance penalty is 2% on Linux and 5% on Windows. CVE-2016-0702 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from master)
-
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> Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from master) Resolved conflicts: crypto/bn/bn_exp.c
-
Viktor Dukhovni authored
Reviewed-by: Emilia Käsper <emilia@openssl.org>
-
Matt Caswell authored
SSLv2 should be off by default. You can only turn it on if you have called SSL_CTX_clear_options(SSL_OP_NO_SSLv2) or SSL_clear_options(SSL_OP_NO_SSLv2). You should not be able to inadvertantly turn it on again via SSL_CONF without having done that first. 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>
-
- Feb 28, 2016
-
-
Kurt Roeckx authored
Also removes an extra initializer, the master branch has a extra field. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- Feb 27, 2016
-
-
FdaSilvaYY authored
Backport of 98637bd3 Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
FdaSilvaYY authored
backport of 3eb70c5e shorter changes Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Andy Polyakov authored
Even though AVX support was added in GAS 2.19 vpclmulqdq was apparently added in 2.20. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit d3cdab17)
-
Kurt Roeckx authored
This reverts commit 6656ba71 . 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>
-
- Feb 24, 2016
-
-
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
-
-
Andy Polyakov authored
RT#4284 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit d9375341)
-
FdaSilvaYY authored
Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Kurt Roeckx <kurt@openssl.org>
-
David Woodhouse authored
This is a partial revert of commit c8491de3 ("GH354: Memory leak fixes"), which was cherry-picked from commit 55500ea7 in OpenSSL 1.1. That commit introduced a change in behaviour which is a regression for software implementing Microsoft Authenticode — which requires a PKCS#7 signature to be validated against explicit external data, even though it's a non-detached signature with its own embedded data. The is fixed differently in OpenSSL 1.1 by commit 6b2ebe43 ("Add PKCS7_NO_DUAL_CONTENT flag"), but that approach isn't viable in the 1.0.2 stable branch, so just comment the offending check back out again. Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
-
- Feb 22, 2016
-
-
Corinna Vinschen authored
Building for the Cygwin distro requires to be able to build debuginfo files. This in turn requires to build object files without stripping. The stripping is performed by the next step after building which creates the debuginfo files. Signed-off-by: Corinna Vinschen <vinschen@redhat.com> (cherry picked from commit 42b8f142 ) Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
In response to RT#4326 Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- 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>
-
Andy Polyakov authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
In backporting from master one modification was mistreated. RT#4210 Reviewed-by: Matt Caswell <matt@openssl.org>
-
- Feb 18, 2016
-
-
Dr. Stephen Henson authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit f6fb7f18)
-
- Feb 16, 2016
-
-
Dr. Stephen Henson authored
Reviewed-by: Tim Hudson <tjh@openssl.org>
-
- Feb 13, 2016
-
-
Andy Polyakov authored
RT#4210 (1.0.2-specific adaptation of 7687f525 ) Reviewed-by: Richard Levitte <levitte@openssl.org>
-