Andy Polyakov [Wed, 18 Jan 2017 23:17:30 +0000 (00:17 +0100)]
crypto/evp: harden RC4_MD5 cipher.
Originally a crash in 32-bit build was reported CHACHA20-POLY1305
cipher. The crash is triggered by truncated packet and is result
of excessive hashing to the edge of accessible memory (or bogus
MAC value is produced if x86 MD5 assembly module is involved). Since
hash operation is read-only it is not considered to be exploitable
beyond a DoS condition.
Bernd Edlinger [Thu, 22 Dec 2016 19:17:29 +0000 (20:17 +0100)]
Fix a ssl session leak due to OOM in lh_SSL_SESSION_insert
- s == NULL can mean c is a new session *or* lh_insert was
unable to create a hash entry.
- use lh_SSL_SESSION_retrieve to check for this error condition.
- If it happens simply remove the extra reference again.
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2138)
(cherry picked from commit 38088ce9934a90d4aea486edbff864f3935342e6)
Matt Caswell [Tue, 22 Nov 2016 17:37:34 +0000 (17:37 +0000)]
Fix SSL_VERIFY_CLIENT_ONCE
The flag SSL_VERIFY_CLIENT_ONCE is documented as follows:
B<Server mode:> only request a client certificate on the initial TLS/SSL
handshake. Do not ask for a client certificate again in case of a
renegotiation. This flag must be used together with SSL_VERIFY_PEER.
B<Client mode:> ignored
But the implementation actually did nothing. After the server sends its
ServerKeyExchange message, the code was checking s->session->peer to see if
it is NULL. If it was set then it did not ask for another client
certificate. However s->session->peer will only be set in the event of a
resumption, but a ServerKeyExchange message is only sent in the event of a
full handshake (i.e. no resumption).
The documentation suggests that the original intention was for this to
have an effect on renegotiation, and resumption doesn't come into it.
The fix is to properly check for renegotiation, not whether there is already
a client certificate in the session.
As far as I can tell this has been broken for a *long* time.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1984)
Richard Levitte [Wed, 18 Jan 2017 15:19:26 +0000 (16:19 +0100)]
Fix DSA parameter generation control error
When setting the digest parameter for DSA parameter generation, the
signature MD was set instead of the parameter generation one.
Fortunately, that's also the one that was used for parameter
generation, but it ultimately meant the parameter generator MD and the
signature MD would always be the same.
Fixes github issue #2016
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2250)
(cherry picked from commit 8a05c4d3b5a1bfb9193ea24e71735e11de7168d2)
Bernd Edlinger [Fri, 23 Dec 2016 13:35:16 +0000 (14:35 +0100)]
Fix a memory leak in RSA_padding_add_PKCS1_OAEP_mgf1
Signed-off-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Matt Caswell <matt@openssl.org>
GH: #2140
(cherry picked from commit c6d215e0d278fcd51ad474a3647b61e1b67290bb)
zero pad DHE public key in ServerKeyExchange message for interop
Some versions of the Microsoft TLS stack have problems when the DHE public key
is encoded with fewer bytes than the DHE prime. (Backported from master)
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1350)
Benjamin Kaduk [Fri, 22 Jul 2016 14:55:48 +0000 (09:55 -0500)]
Fix a bug in clienthello processing
- Always process ALPN (previously there was an early return in the
certificate status handling)
1.0.2 did not have the double-alert issue from master, but it seems
cleanest to pull in the structural change to alert handling anyway
and jump to f_err instead of err to send the alert in the caller.
Andy Polyakov [Fri, 9 Dec 2016 14:26:19 +0000 (15:26 +0100)]
perlasm/x86_64-xlate.pl: refine sign extension in ea package.
$1<<32>>32 worked fine with either 32- or 64-bit perl for a good while,
relying on quirk that [pure] 32-bit perl performed it as $1<<0>>0. But
this apparently changed in some version past minimally required 5.10,
and operation result became 0. Yet, it went unnoticed for another while,
because most perl package providers configure their packages with
-Duse64bitint option.
Richard Levitte [Fri, 9 Dec 2016 22:41:01 +0000 (23:41 +0100)]
VMS UI_OpenSSL: if the TT device isn't a tty, flag instead of error
On all platforms, if the controlling tty isn't an actual tty, this is
flagged by setting is_a_tty to zero... except on VMS, where this was
treated as an error. Change this to behave like the other platforms.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2064)
Vitezslav Cizek [Thu, 24 Nov 2016 12:21:41 +0000 (13:21 +0100)]
apps/speed.c: Fix crash when config loading fails
Move rsa_key initialization in front of load_config().
If loading the config fails, rsa_key isn't initialized and may
cause invalid free() in the end: cleanup.
Remove superfluous memset.
Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
Beat Bolli [Fri, 18 Nov 2016 08:53:48 +0000 (09:53 +0100)]
Use consistent variable names
In the X509_NAME_get_index_by_NID.pod example, the initialized variable is called
"loc", but the one used in the for loop is called "lastpos". Make the names match.
CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1949)
mklink: Do not needlessly overwrite linked files...
... on systems with symlinks.
Creating or overwriting a symlink sets the file ctime to the current time.
This causes needless rebuilds because the time of all the headers is
changed, and apparently make considers the link's time rather than the
time of the target.
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1370)
When Makefile/opensslconf.h is unchanged, don't write it at all.
Currently every time Configure is executed, these files are overwritten.
Makefile leads to regeneration of buildinf.h, and opensslconf.h is itself
a central header.
As a result, Configure triggers full rebuild, even if nothing is changed.
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1370)
Rich Salz [Tue, 15 Nov 2016 23:54:28 +0000 (18:54 -0500)]
Check return value of some BN functions.
Factorise multiple bn_get_top(group->field) calls
Add missing checks on some conditional BN_copy return value
Add missing checks on some BN_copy return value
Add missing checks on a few bn_wexpand return value
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1626)
(cherry picked from commit 78e09b53a40729f5e99829ccc733b592bd22fea1)
Rich Salz [Fri, 4 Nov 2016 14:27:47 +0000 (10:27 -0400)]
Missed a mention of RT
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1849)
(cherry picked from commit 1e62cc12f35408508594be254f40bf9b65d2a3a9)
Matt Caswell [Wed, 2 Nov 2016 22:26:17 +0000 (22:26 +0000)]
Fail if an unrecognised record type is received
TLS1.0 and TLS1.1 say you SHOULD ignore unrecognised record types, but
TLS 1.2 says you MUST send an unexpected message alert. We swap to the
TLS 1.2 behaviour for all protocol versions to prevent issues where no
progress is being made and the peer continually sends unrecognised record
types, using up resources processing them.
Matt Caswell [Wed, 2 Nov 2016 15:36:06 +0000 (15:36 +0000)]
Fix heartbeat_test
The heartbeat_test reaches into the internals of libssl and calls some
internal functions. It then checks the return value to check its what it
expected. However commit fa4c37457 changed the return value of these
internal functions, and now the test is failing.
The solution is to update the test to look for the new return value.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Benjamin Kaduk [Mon, 26 Sep 2016 20:30:42 +0000 (15:30 -0500)]
Fix grammar-o in CONTRIBUTING
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1625)
(cherry picked from commit e4d94269a5a41594852dc60716500580f1d47cef)
Matt Caswell [Fri, 14 Oct 2016 12:07:00 +0000 (13:07 +0100)]
Ensure we have length checks for all extensions
The previous commit inspired a review of all the length checks for the
extension adding code. This adds more robust checks and adds checks where
some were missing previously. The real solution for this is to use WPACKET
which is currently in master - but that cannot be applied to release
branches.
Matt Caswell [Fri, 14 Oct 2016 10:49:06 +0000 (11:49 +0100)]
Fix length check writing status request extension
The status request extension did not correctly check its length, meaning
that writing the extension could go 2 bytes beyond the buffer size. In
practice this makes little difference because, due to logic in buffer.c the
buffer is actually over allocated by approximately 5k!
Matt Caswell [Fri, 21 Oct 2016 13:49:33 +0000 (14:49 +0100)]
A zero return from BIO_read/BIO_write() could be retryable
A zero return from BIO_read()/BIO_write() could mean that an IO operation
is retryable. A zero return from SSL_read()/SSL_write() means that the
connection has been closed down (either cleanly or not). Therefore we
should not propagate a zero return value from BIO_read()/BIO_write() back
up the stack to SSL_read()/SSL_write(). This could result in a retryable
failure being treated as fatal.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Rich Salz [Sat, 22 Oct 2016 07:53:47 +0000 (03:53 -0400)]
Correctly find all critical CRL extensions
Unhandled critical CRL extensions were not detected if they appeared
after the handled ones. (GitHub issue 1757). Thanks to John Chuah
for reporting this.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1769)
Richard Levitte [Wed, 28 Sep 2016 22:40:20 +0000 (00:40 +0200)]
If an engine comes up explicitely, it must also come down explicitely
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)
Patrick Steuer [Mon, 17 Oct 2016 08:30:33 +0000 (10:30 +0200)]
Fix strict-warnings build
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
Patrick Steuer [Mon, 17 Oct 2016 08:24:49 +0000 (10:24 +0200)]
Fix strict-warnings build
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
Matt Caswell [Wed, 12 Oct 2016 15:43:03 +0000 (16:43 +0100)]
Ensure we handle len == 0 in ERR_err_string_n
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/
Rich Salz [Wed, 12 Oct 2016 19:49:06 +0000 (15:49 -0400)]
RT is put out to pasture
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1702)
(cherry picked from commit 7954dced19a7e59e7055eab95a981fa943c7d100)
Richard Levitte [Wed, 28 Sep 2016 19:28:00 +0000 (21:28 +0200)]
apps/apps.c: initialize and de-initialize engine around key loading
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)
David Woodhouse [Wed, 28 Sep 2016 13:31:22 +0000 (14:31 +0100)]
Call ENGINE_init() before trying to use keys from engine
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)
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>
Matt Caswell [Fri, 9 Sep 2016 09:53:39 +0000 (10:53 +0100)]
Fix a mem leak in NPN handling
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.
Matt Caswell [Fri, 9 Sep 2016 09:08:45 +0000 (10:08 +0100)]
Fix OCSP Status Request extension unbounded memory growth
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.
Matt Caswell [Wed, 21 Sep 2016 13:48:16 +0000 (14:48 +0100)]
Don't allow too many consecutive warning alerts
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.
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.
projects / openssl / log