It is important that output to the trace channels occurs only inside
a trace group. This precondtion is satisfied whenever the standard
TRACE macros are used. It can be violated only by a bad programming
mistake, like copying the 'trc_out' pointer and using it outside
the trace group.
This commit enforces correct pairing of the OSSL_TRACE_CTRL_BEGIN and
OSSL_TRACE_CTRL_END callbacks, and checks that OSSL_TRACE_CTRL_WRITE
callbacks only occur within such groups.
While implementing it, it turned out that the group assertion failed
apps/openssl.c:152: OpenSSL internal error: \
Assertion failed: trace_data->ingroup
because the set_trace_data() function invokes some callbacks which
generate trace output, but the correct channel type was set only
after the set_trace_data() call.
To fix the failed assertions, the correct channel type is now set
inside the set_trace_data() call, instead of doing it afterwards.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8463)
The openssl app registers trace callbacks which automatically
set a line prefix in the OSSL_TRACE_CTRL_BEGIN callback.
This prefix needs to be cleared in the OSSL_TRACE_CTRL_END
callback, otherwise a memory leak is reported when openssl
is built with crypto-mdebug enabled.
This leak causes the tests to fail when tracing and memory
debugging are enabled.
The leak can be observed by any command that produces trace
output, e.g. by
OPENSSL_TRACE=ANY util/shlib_wrap.sh apps/openssl version
...
[00:19:14] 4061 file=apps/bf_prefix.c, line=152, ...
26 bytes leaked in 1 chunks
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8463)
Since the term 'channel' is already used as synonym for a BIO object attached
to a trace category, having a 't_channel' channel type and a 't_callback' channel
type somehow overburdens this term. For that reason the type enum constants are
renamed to 'SIMPE_CHANNEL' and 'CALLBACK_CHANNEL'.
(The conversion to capital letters was done to comply to the coding style.)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8463)
When tracing is disabled, don't generate errors, especially during
init. Instead, just pretend the everything is fine.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8475)
This queries the provider for its available functionality (unless a
matching method structured is already cached, in which case that's
used instead), and creates method structure with the help of a passed
constructor. The result is cached if the provider allows it (or if
caching is forced).
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8340)
Provide a number of functions to allow parameters to be set and
retrieved in a type safe manner. Functions are provided for many
integral types plus double, BIGNUM, UTF8 strings and OCTET strings.
All of the integer functions will widen the parameter data as
required. This permits a degree of malleability in the parameter
definition. For example a type can be changed from a thirty two bit
integer to a sixty four bit one without changing application code.
Only four and eight byte integral sizes are supported here.
A pair of real functions are available for doubles.
A pair of functions is available for BIGNUMs. These accept any sized
unsigned integer input and convert to/from a BIGNUM.
For each OCTET and UTF8 strings, four functions are defined. This
provide get and set functionality for string and for pointers to
strings. The latter avoiding copies but have other inherent risks.
Finally, some utility macros and functions are defined to allow
OSSL_PARAM definition arrays to be specified in a simple manner.
There are two macro and one function for most types. The exception
being BIGNUM, for which there is one macro and one function.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8451)
The OSSL_PARAM attribute names |buffer| and |buffer_size| may lead to
confusion, as they may make some think that the memory pointed at is
an intermediate memory are. This is not generally the case, so we
rename |buffer| and |buffer_size| to |data| and |data_size|
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8451)
in INSTALL, Configure, crypto/build.info, include/openssl/crmferr.h,
crypto/err/, include/openssl/err.h, and (to be updated:) util/libcrypto.num
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7646)
featuring 6x"horizontal" code path which is up to 25%
faster than present 4x"vertical" for larger blocks.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8287)
Adding a provider means creating an internal provier object and adding
it to the store. This allows the addition of built in providers, be it
in the OpenSSL libraries or in any application.
"Loading" a provider is defined broadly. A built in provider is already
"loaded" in essence and only needs activating, while a provider in a
dynamically loadable module requires actually loading the module itself.
In this API, "loading" a provider does both.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8287)
The OSSL_PROVIDER is the core object involved in loading a provider
module, initialize a provider and do the initial communication of
provider wide and core wide dispatch tables.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8287)
The argument to this function is declared const in the header file. However
the implementation did not have this. This issue is only visible when using
enable-zlib.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8433)
The function felem_diff_128_64 in ecp_nistp521.c substracts the number |in|
from |out| mod p. In order to avoid underflow it first adds 32p mod p
(which is equivalent to 0 mod p) to |out|. The comments and variable naming
suggest that the original author intended to add 64p mod p. In fact it
has been shown that with certain unusual co-ordinates it is possible to
cause an underflow in this function when only adding 32p mod p while
performing a point double operation. By changing this to 64p mod p the
underflow is avoided.
It turns out to be quite difficult to construct points that satisfy the
underflow criteria although this has been done and the underflow
demonstrated. However none of these points are actually on the curve.
Finding points that satisfy the underflow criteria and are also *on* the
curve is considered significantly more difficult. For this reason we do
not believe that this issue is currently practically exploitable and
therefore no CVE has been assigned.
This only impacts builds using the enable-ec_nistp_64_gcc_128 Configure
option.
With thanks to Bo-Yin Yang, Billy Brumley and Dr Liu for their significant
help in investigating this issue.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8405)
ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for
every encryption operation. RFC 7539 specifies that the nonce value (IV)
should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and
front pads the nonce with 0 bytes if it is less than 12 bytes. However it
also incorrectly allows a nonce to be set of up to 16 bytes. In this case
only the last 12 bytes are significant and any additional leading bytes are
ignored.
It is a requirement of using this cipher that nonce values are unique.
Messages encrypted using a reused nonce value are susceptible to serious
confidentiality and integrity attacks. If an application changes the
default nonce length to be longer than 12 bytes and then makes a change to
the leading bytes of the nonce expecting the new value to be a new unique
nonce then such an application could inadvertently encrypt messages with a
reused nonce.
Additionally the ignored bytes in a long nonce are not covered by the
integrity guarantee of this cipher. Any application that relies on the
integrity of these ignored leading bytes of a long nonce may be further
affected.
Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe
because no such use sets such a long nonce value. However user
applications that use this cipher directly and set a non-default nonce
length to be longer than 12 bytes may be vulnerable.
CVE-2019-1543
Fixes#8345
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8406)
This disabled the tracing functionality by making functions do
nothing, and making convenience macros produce dead code.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8198)
The idea is that the application shall be able to register output
channels or callbacks to print tracing output as it sees fit.
OpenSSL internals, on the other hand, want to print thoses texts using
normal printing routines, such as BIO_printf() or BIO_dump() through
well defined BIOs.
When the application registers callbacks, the tracing functionality
sets up an internal BIO that simply forwards received text to the
appropriate application provided callback.
Co-authored-by: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8198)
This should never reduce the range covered and might increase it on some
platforms.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8415)
The "hw" and "hw-.*" style options are historical artifacts, sprung
from the time when ENGINE was first designed, with hardware crypto
accelerators and HSMs in mind.
Today, these options have largely lost their value, replaced by
options such as "no-{foo}eng" and "no-engine".
This completes the transition by making "hw" and "hw-.*" deprecated,
but automatically translated into more modern variants of the same.
In the process, we get rid of the last regular expression in
Configure's @disablables, a feature that was ill supported anyway.
Also, padlock now gets treated just as every other engine.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8380)
GNU strerror_r may return either a pointer to a string that the function
stores in buf, or a pointer to some (immutable) static string in which case
buf is unused.
In such a case we need to set buf manually.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8371)
Use select to wait for /dev/random in readable state,
but do not actually read anything from /dev/random,
use /dev/urandom first.
Use linux define __NR_getrandom instead of the
glibc define SYS_getrandom, in case the kernel headers
are more current than the glibc headers.
Fixes#8215
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/8251)
SSH's KDF is defined in RFC 4253 in Section 7.2
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7290)
