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: Matt Caswell <matt@openssl.org>
Matt Caswell [Sat, 10 Sep 2016 20:24:40 +0000 (21:24 +0100)]
Fix a hang with SSL_peek()
If while calling SSL_peek() we read an empty record then we go into an
infinite loop, continually trying to read data from the empty record and
never making any progress. This could be exploited by a malicious peer in
a Denial Of Service attack.
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.
Richard Levitte [Wed, 21 Sep 2016 12:44:42 +0000 (14:44 +0200)]
test/x509aux.c: Fix argv loop
There are cases when argc is more trustable than proper argv termination.
Since we trust argc in all other test programs, we might as well treat it
the same way in this program.
Matt Caswell [Mon, 19 Sep 2016 10:57:07 +0000 (11:57 +0100)]
Excessive allocation of memory in dtls1_preprocess_fragment()
This issue is very similar to CVE-2016-6307 described in the previous
commit. The underlying defect is different but the security analysis and
impacts are the same except that it impacts DTLS.
A DTLS message includes 3 bytes for its length in the header for the
message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect TLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
Matt Caswell [Mon, 19 Sep 2016 10:39:21 +0000 (11:39 +0100)]
Excessive allocation of memory in tls_get_message_header()
A TLS message includes 3 bytes for its length in the header for the message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect DTLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
Matt Caswell [Wed, 21 Sep 2016 13:07:31 +0000 (14:07 +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.
Matt Caswell [Thu, 8 Sep 2016 10:06:29 +0000 (11:06 +0100)]
Convert num_alloc to a size_t in stack.c and tweak style
We were casting num_alloc to size_t in lots of places, or just using it in
a context where size_t makes more sense - so convert it. This simplifies
the code a bit.
Also tweak the style in stack.c a bit following on from the previous
commit
Richard Levitte [Sat, 17 Sep 2016 19:57:29 +0000 (21:57 +0200)]
Have the configuration options 'no-err' and 'no-async' work again
In an earlier attempt to simplify the processing of disabled options,
'no-err' and 'no-async' stopped working properly. 'err' and 'async'
are directories under 'crypto/', but they are special insofar that
they can't be simply skipped, like all the algorithm directories can,
so they need special treatment among the disablable things.
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.
Matt Caswell [Thu, 8 Sep 2016 13:32:27 +0000 (14:32 +0100)]
Add some sanity checks around usage of t_fromb64()
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.
Viktor Szakats [Tue, 30 Aug 2016 01:01:16 +0000 (03:01 +0200)]
s_client: avoid warning on Windows/MS-DOS systems
it appears when using gcc/mingw:
```
apps/s_client.c:815:9: warning: variable 'at_eof' set but not used [-Wunused-but-set-variable]
int at_eof = 0;
^~~~~~
``` Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1512)
(cherry picked from commit d485640b8083aea895ecf31b4ea6a338ee561b67)
Matt Caswell [Mon, 12 Sep 2016 10:04:51 +0000 (11:04 +0100)]
Abort on unrecognised warning alerts
A peer continually sending unrecognised warning alerts could mean that we
make no progress on a connection. We should abort rather than continuing if
we receive an unrecognised warning alert.
Matt Caswell [Mon, 5 Sep 2016 13:12:58 +0000 (14:12 +0100)]
Fix mem leaks during auto-deinit
Certain functions are automatically called during auto-deinit in order
to deallocate resources. However, if we have never entered a function which
marks lib crypto as inited then they never get called. This can happen if
the user only ever makes use of a small sub-set of functions that don't hit
the auto-init code.
This commit ensures all such resources deallocated by these functions also
init libcrypto when they are initially allocated.
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Ben Laurie <ben@openssl.org>
(cherry picked from commit 135648bcd0e9db029582d3d7627a90a1b566c5d6)
Richard Levitte [Wed, 7 Sep 2016 18:56:20 +0000 (20:56 +0200)]
Allow asan, msan and ubsan to be configured with shared libraries
The background story is that util/shlib_wrap.sh was setting LD_PRELOAD
or similar platform dependent variables, just in case the shared
libraries were built with -rpath. Unfortunately, this doesn't work
too well with asan, msan or ubsan.
So, the solution is to forbid the combination of shared libraries,
-rpath and any of the sanity analyzers we can configure.
This changes util/shlib_wrap.sh so it only contains the code that sets
LD_PRELOAD when -rpath has been used when configuring.
David Woodhouse [Wed, 7 Sep 2016 15:53:18 +0000 (16:53 +0100)]
Avoid EVP_PKEY_cmp() crash on EC keys without public component
Some hardware devices don't provide the public EC_POINT data. The only
way for X509_check_private_key() to validate that the key matches a
given certificate is to actually perform a sign operation and then
verify it using the public key in the certificate.
Maybe that can come later, as discussed in issue 1532. But for now let's
at least make it fail gracefully and not crash.
GH: 1532
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1547)
Richard Levitte [Tue, 6 Sep 2016 18:14:33 +0000 (20:14 +0200)]
Configure: Reorganise the checking of disabled options
The way we figured out what options are crypto algorithms and what are
something other was somewhat sketchy. This change bases the
distinction on available sdirs instead.
Never output -0; make "negative zero" an impossibility.
Do better checking on BN_rand top/bottom requirements and #bits.
Update doc.
Ignoring trailing garbage in BN_asc2bn.
Port this commit from boringSSL: https://boringssl.googlesource.com/boringssl/+/899b9b19a4cd3fe526aaf5047ab9234cdca19f7d%5E!/
Ensure |BN_div| never gives negative zero in the no_branch code.
Have |bn_correct_top| fix |bn->neg| if the input is zero so that we
don't have negative zeros lying around.
Richard Levitte [Sun, 4 Sep 2016 06:10:22 +0000 (08:10 +0200)]
Unix build: have the makedepend and cc actions in one recipe
In the case of using an independent makedepend, we had split that into
two separate recipes, one depending on the other. However, there are
cases where the makedepend recipe was always trying, but doesn't
update the time stamp of the .d file because there are no actual
changes, and thereby causing constant updates of the object files.
This change makes one recipe that takes care of both makedepend och
cc, thereby avoiding these extra updates.
Since vendor assembler can't assemble our modules with -KPIC flag,
it, assembly support, was not available as an option. But this
means lack of side-channel resistant code, which is incompatible
with security by todays standards.
Richard Levitte [Wed, 31 Aug 2016 15:07:44 +0000 (17:07 +0200)]
Make it possible to disable fuzz testing
These tests take a very long time on some platforms, and arent't
always strictly necessary. This makes it possible to turn them
off. The necessary binaries are still built, though, in case
someone still wants to do a manual run.
Matt Caswell [Tue, 30 Aug 2016 13:20:18 +0000 (14:20 +0100)]
Add some CertStatus tests
The previous commit revealed a long standing problem where CertStatus
processing was broken in DTLS. This would have been revealed by better
testing - so add some!
Matt Caswell [Tue, 30 Aug 2016 10:32:49 +0000 (11:32 +0100)]
Ensure the CertStatus message adds a DTLS message header where needed
The function tls_construct_cert_status() is called by both TLS and DTLS
code. However it only ever constructed a TLS message header for the message
which obviously failed in DTLS.