In apps/apps.c, one can set up an engine with setup_engine().
However, we freed the structural reference immediately, which means
that for engines that don't already have a structural reference
somewhere else (because it has registered at least one cipher or digest
algorithm method, and therefore gets a functional reference through the
ENGINE_set_default() call), we end up returning an invalid reference.
Instead, the function release_engine() is added, and called at the end
of the routines that call setup_engine().
Originally, the ENGINE API wasn't designed for this to happen, an
engine had to register at least one algorithm method, and was
especially expected to register the algorithms corresponding to the
key types that could be stored and hidden in hardware. However, it
turns out that some engines will not register those algorithms with
the ENGINE_set_{algo}, ENGINE_set_cipher or ENGINE_set_digest
functions, as they only want the methods to be used for keys, not as
general crypto accelerator methods. That may cause ENGINE_set_default()
to do nothing, and no functional reference is therefore made, leading
to a premature deallocation of the engine and it thereby becoming
unavailable when trying to fetch a key.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1644)
crypto/evp/e_aes.c: Types of inp and out parameters of AES_xts_en/decrypt
functions need to be changed from char to unsigned char to avoid build
error due to -Werror=incompatible-pointer-types.
crypto/aes/asm/aes-s390x.pl: Comments need to reflect the above change.
Signed-off-by: Patrick Steuer <psteuer@mail.de>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
CLA: trivial
crypto/s390xcap.c: cryptlib.h needs to be included for OPENSSL_cpuid_setup
function prototype is located there to avoid build error due to
-Werror=missing-prototypes.
Signed-off-by: Patrick Steuer <psteuer@mail.de>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
CLA: trivial
These are implemented as macros delegating to `EVP_DigestUpdate`, which
takes a `size_t` as its third argument, not an `unsigned int`.
CLA: trivial
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 8bdce8d160)
If len == 0 in a call to ERR_error_string_n() then we can read beyond the
end of the buffer. Really applications should not be calling this function
with len == 0, but we shouldn't be letting it through either!
Thanks to Agostino Sarubbo for reporting this issue. Agostino's blog on
this issue is available here:
https://blogs.gentoo.org/ago/2016/10/14/openssl-libcrypto-stack-based-buffer-overflow-in-err_error_string_n-err-c/
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit e5c1361580)
The SWEET32 fix moved 3DES from HIGH to MEDIUM, but omitted SSL2.
CLA: trivial
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1683)
Before loading a key from an engine, it may need to be initialized.
When done loading the key, we must de-initialize the engine.
(if the engine is already initialized somehow, only the reference
counter will be incremented then decremented)
Reviewed-by: Stephen Henson <steve@openssl.org>
(cherry picked from commit 49e476a538)
Things like 'openssl s_client' only ever worked with keys from an engine
which provided a default generic method for some key type — because it
called ENGINE_set_default() and that ended up being an implicit
initialisation and functional refcount.
But an engine which doesn't provide generic methods doesn't get
initialised, and then when you try to use it you get an error:
cannot load client certificate private key file from engine
140688147056384:error:26096075:engine routines:ENGINE_load_private_key:not initialised:crypto/engine/eng_pkey.c:66:
unable to load client certificate private key file
cf. https://github.com/OpenSC/libp11/issues/107 (in which we discover
that engine_pkcs11 *used* to provide generic methods that OpenSSL would
try to use for ephemeral DH keys when negotiating ECDHE cipher suites in
TLS, and that didn't work out very well.)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1640)
Note: this was accidentally omitted from OpenSSL 1.0.2 branch.
Without this fix any attempt to use CRLs will crash.
CVE-2016-7052
Thanks to Bruce Stephens and Thomas Jakobi for reporting this issue.
Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Add a missing ifdef. Same change is already present in master.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1100)
Russian GOST ciphersuites are vulnerable to the KCI attack because they use
long-term keys to establish the connection when ssl client authorization is
on. This change brings the GOST implementation into line with the latest
specs in order to avoid the attack. It should not break backwards
compatibility.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
If a server sent multiple NPN extensions in a single ClientHello then a
mem leak can occur. This will only happen where the client has requested
NPN in the first place. It does not occur during renegotiation. Therefore
the maximum that could be leaked in a single connection with a malicious
server is 64k (the maximum size of the ServerHello extensions section). As
this is client side, only occurs if NPN has been requested and does not
occur during renegotiation this is unlikely to be exploitable.
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
A malicious client can send an excessively large OCSP Status Request
extension. If that client continually requests renegotiation,
sending a large OCSP Status Request extension each time, then there will
be unbounded memory growth on the server. This will eventually lead to a
Denial Of Service attack through memory exhaustion. Servers with a
default configuration are vulnerable even if they do not support OCSP.
Builds using the "no-ocsp" build time option are not affected.
I have also checked other extensions to see if they suffer from a similar
problem but I could not find any other issues.
CVE-2016-6304
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Certain warning alerts are ignored if they are received. This can mean that
no progress will be made if one peer continually sends those warning alerts.
Implement a count so that we abort the connection if we receive too many.
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Grow TLS/DTLS 16 bytes more than strictly necessary as a precaution against
OOB reads. In most cases this will have no effect because the message buffer
will be large enough already.
Reviewed-by: Matt Caswell <matt@openssl.org>
In ssl3_get_client_certificate, ssl3_get_server_certificate and
ssl3_get_certificate_request check we have enough room
before reading a length.
Thanks to Shi Lei (Gear Team, Qihoo 360 Inc.) for reporting these bugs.
CVE-2016-6306
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
We should check the last BN_CTX_get() call to ensure that it isn't NULL
before we try and use any of the allocated BIGNUMs.
Issue reported by Shi Lei.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 1ff7425d61)
This helps with program code linked against static builds accessing a uninitialized ->engine pointer.
CLA: none; trivial
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1540)
This reverts commit 15d8174932.
There were some unexpected side effects to this commit, e.g. in SSLv3 a
warning alert gets sent "no_certificate" if a client does not send a
Certificate during Client Auth. With the above commit this causes the
connection to abort, which is incorrect. There may be some other edge cases
like this so we need to have a rethink on this.
Reviewed-by: Tim Hudson <tjh@openssl.org>
This is needed, because on VMS, select() can only be used on sockets. being
able to use select() on all kinds of file descriptors is unique to Unix.
So, the solution for VMS is to create a layer that translates input from
standard input to socket communication.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
This fixes the following error when building with no particular pointer size
is specified (implied 32 bit):
static void *(*realloc_func) (void *, size_t) = realloc;
................................................^
%CC-E-UNDECLARED, In the initializer for realloc_func, "_realloc32" is not declared.
at line number 93 in file DEV:[OPENSSL102.crypto]mem.c;1
Reviewed-by: Andy Polyakov <appro@openssl.org>
The internal SRP function t_fromb64() converts from base64 to binary. It
does not validate that the size of the destination is sufficiently large -
that is up to the callers. In some places there was such a check, but not
in others.
Add an argument to t_fromb64() to provide the size of the destination
buffer and validate that we don't write too much data. Also add some sanity
checks to the callers where appropriate.
With thanks to Shi Lei for reporting this issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 73f0df8331)
Richard Levitte
Patrick Steuer
Steven Fackler
Matt Caswell
Vitezslav Cizek
Rich Salz
Kurt Cancemi
David Woodhouse
Dirk Feytons
Dmitry Belyavsky
Dr. Stephen Henson
Marcus Meissner