Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
Historically we used to implement standalone base64 code for SRP. This
was replaced by commit 3d3f21aa with the standard base64 processing code.
However, the SRP base64 code was designed to be compatible with other SRP
libraries (notably libsrp, but also others) that use a variant of standard
base64. Specifically a different alphabet is used and no padding '='
characters are used. Instead 0 padding is added to the front of the string.
By changing to standard base64 we change the behaviour of the API which may
impact interoperability. It also means that SRP verifier files created prior
to 1.1.1 would not be readable in 1.1.1 and vice versa.
Instead we expand our standard base64 processing with the capability to be
able to read and generate the SRP base64 variant.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5925)
Previously they were using EVP_EncodeBlock/EVP_DecodeBlock. These are low
level functions that do not handle padding characters. This was causing
the SRP code to fail. One side effect of using EVP_EncodeUpdate is that
it inserts newlines which is not what we need in SRP so we add a flag to
avoid that.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5925)
Since return is inconsistent, I removed unnecessary parentheses and
unified them.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4541)
Previously EVP_EncodeUpdate returned a void. However there are a couple
of error conditions that can occur. Therefore the return type has been
changed to an int, with 0 indicating error and 1 indicating success.
Reviewed-by: Rich Salz <rsalz@openssl.org>
With the EVP_EncodeUpdate function it is the caller's responsibility to
determine how big the output buffer should be. The function writes the
amount actually used to |*outl|. However this could go negative with a
sufficiently large value for |inl|. We add a check for this error
condition.
Reviewed-by: Richard Levitte <levitte@openssl.org>
An overflow can occur in the EVP_EncodeUpdate function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption. Due to the very large amounts of data involved this will most
likely result in a crash.
Internally to OpenSSL the EVP_EncodeUpdate function is primarly used by the
PEM_write_bio* family of functions. These are mainly used within the
OpenSSL command line applications, so any application which processes
data from an untrusted source and outputs it as a PEM file should be
considered vulnerable to this issue.
User applications that call these APIs directly with large amounts of
untrusted data may also be vulnerable.
Issue reported by Guido Vranken.
CVE-2016-2105
Reviewed-by: Richard Levitte <levitte@openssl.org>
Don't cast malloc-family return values.
Also found some places where (a) blank line was missing; and (b)
the *wrong* return value was checked.
Reviewed-by: Richard Levitte <levitte@openssl.org>
This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Rewrite EVP_DecodeUpdate.
In particular: reject extra trailing padding, and padding in the middle
of the content. Don't limit line length. Add tests.
Previously, the behaviour was ill-defined, and depended on the position
of the padding within the input.
In addition, this appears to fix a possible two-byte oob read.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Dr Stephen Henson <steve@openssl.org>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
There was already a sanity check to ensure the passed buffer length is not
zero. Extend this to ensure that it also not negative. Thanks to Kevin
Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for
reporting this issue.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This removes all code surrounded by '#ifdef undef'
One case is left: memmove() replaced by open-coded for loop,
in crypto/stack/stack.c That needs further review.
Also removed a couple of instances of /* dead code */ if I saw them
while doing the main removal.
Reviewed-by: Matt Caswell <matt@openssl.org>
This patch resolves RT ticket #2608.
Thanks to Robert Dugal for originally spotting this, and to David
Ramos for noticing that the ball had been dropped.
Signed-off-by: Geoff Thorpe <geoff@openssl.org>
knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.
functions and macros.
This change has associated tags: LEVITTE_before_const and
LEVITTE_after_const. Those will be removed when this change has been
properly reviewed.
I have tried to convert 'len' type variable declarations to unsigned as a
means to address these warnings when appropriate, but when in doubt I have
used casts in the comparisons instead. The better solution (that would get
us all lynched by API users) would be to go through and convert all the
function prototypes and structure definitions to use unsigned variables
except when signed is necessary. The proliferation of (signed) "int" for
strictly non-negative uses is unfortunate.
records, EVP_EncodeUpdate() may misbehave. This happens when there's
a record boundary between the two ending b64 equal signs, which makes
EVP_EncodeUpdate think there has been more than one EOF, and therefore
add an extra NUL at the end of the output buffer. This fix corrects
that problem.
