- Feb 26, 2016
-
-
J Mohan Rao Arisankala authored
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
J Mohan Rao Arisankala authored
- In error paths, EVP_MD_CTX allocated by the callee is not released. - Checking method before accessing Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
David Woodhouse authored
We are using strcmp() as the cmp_func, where in the EDK2 environment strcmp actually ends up being the external AsciiStrCmp() function — an EFI library function defined with the Microsoft ABI. This means that we can't just assign function pointers to it, since in GCC-hosted builds the ABI of any function *not* explicitly marked EFIAPI is the native SysV ABI. Arguably this stupidity ought to be resolved on the UEFI side, but in the general case that would mean that we need to provide ABI-compatible wrappers for *all* the "standard" functions, just in case they're used like this. And in fact we already have a workaround here for DEC C. So instead of playing games with casting function pointers, it's nicer just to use a simple function to wrap the strcmp() call. That cleans up the DEC C workaround, *and* it works around the UEFI bogosity at the same time. Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Kurt Roeckx <kurt@openssl.org>
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org>
-
Matt Caswell authored
mkdef.pl was issuing the following error: Use of uninitialized value within %tag in numeric eq (==) at util/mkdef.pl line 560, <IN> line 92 This was because it was treating a __cplusplus "#ifdef" check as a "tag" but then skipping over the corresponding "#endif". Therefore after processing a file it still had "left over" tags from processing the previous file. It was also getting confused by "#if" checks that didn't match is pre-defined styles. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
build.info needed a slight update, one more include directory. Reviewed-by: Matt Caswell <matt@openssl.org>
-
Alessandro Ghedini authored
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
Richard Levitte authored
They now default to " " as separator, but that can be overridden by having a hash with parameters as last argument. The only currently recognised parameter is `separator'. The special separator `undef' will force the result to become a list rather than a concatenated string. Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Rich Salz authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
- 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>
-
FdaSilvaYY authored
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
FdaSilvaYY authored
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Rich Salz authored
Simplifies calling code. Also fixed up any !ptr tests that were nearby, turning them into NULL tests. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Rich Salz authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Rob Percival authored
Reviewed-by: Ben Laurie <ben@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Adam Eijdenberg authored
Reviewed-by: Ben Laurie <ben@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Rich Salz authored
Fixes github issue 463. Building the app without OPENSSL_NO_SOCK isn't supported, so only do OPENSSL_NO_OCSP. Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Rich Salz authored
Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Rich Salz authored
Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Rich Salz authored
See also the discussion in https://github.com/openssl/openssl/pull/455 Reviewed-by: Andy Polyakov <appro@openssl.org>
-
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>
-
Richard Levitte authored
Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Richard Levitte authored
If the local system doesn't have GNU C or clang, and not even makedepend, the build will stop because the call of 'makedepend' fails. This changes so the build won't stop because of such failure. The result will be empty .d files, and that's ok. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
J Mohan Rao Arisankala authored
Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
Rich Salz authored
Reviewed-by: Emilia Käsper <emilia@openssl.org>
-
- Feb 24, 2016
-
-
Flavio Medeiros authored
This is also RT 4137 Signed-off-by: Rich Salz <rsalz@akamai.com> Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Rich Salz authored
Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Dr. Stephen Henson authored
The ssl_set_masks() function no longer depends on the cipher. This also means there is no need to set the masks for each cipher in ssl3_choose_cipher. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- Feb 23, 2016
-
-
Viktor Dukhovni authored
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
-
Roumen Petrov authored
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Andy Polyakov authored
RT#4284 Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Andy Polyakov authored
RT#4284 Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Different assembler versions disagree on how to interpret #-1 as argument to vmov.i64, as 0xffffffffffffffff or 0x00000000ffffffff. So replace it with something they can't disagree on. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
David Woodhouse authored
The entire contents of <internal/bn_conf.h> are unwanted in the UEFI build because we have to do it differently there. To support building for both 32-bit and 64-bit platforms without re-running the OpenSSL Configure script, the EDK2 environment defines THIRTY_TWO_BIT or SIXTY_FOUR_BIT for itself according to the target platform. The current setup is broken, though. It checks for OPENSSL_SYS_UEFI but before it's actually defined, since opensslconf.h hasn't yet been included. Let's fix that by including opensslconf.h. And also let's move the bn_conf.h doesn't even need to *exist* in the UEFI build environment. This is also GH PR736. Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
-
J Mohan Rao Arisankala authored
Removing code, where memory was getting allocated for an unused variable Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
Rich Salz authored
Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
-
- Feb 22, 2016
-
-
Richard Levitte authored
These flags are limitting needlessly, are often patched by packagers, and should be specified on the configuration command line by anyone who desires for it to be specific rather than forced by us. This work was already done with mingw when those configs were worked on, now it gets applied to the remaining configs. Reviewed-by: Andy Polyakov <appro@openssl.org>
-