The DTLS implementation provides some protection against replay attacks
in accordance with RFC6347 section 4.1.2.6.
A sliding "window" of valid record sequence numbers is maintained with
the "right" hand edge of the window set to the highest sequence number we
have received so far. Records that arrive that are off the "left" hand
edge of the window are rejected. Records within the window are checked
against a list of records received so far. If we already received it then
we also reject the new record.
If we have not already received the record, or the sequence number is off
the right hand edge of the window then we verify the MAC of the record.
If MAC verification fails then we discard the record. Otherwise we mark
the record as received. If the sequence number was off the right hand edge
of the window, then we slide the window along so that the right hand edge
is in line with the newly received sequence number.
Records may arrive for future epochs, i.e. a record from after a CCS being
sent, can arrive before the CCS does if the packets get re-ordered. As we
have not yet received the CCS we are not yet in a position to decrypt or
validate the MAC of those records. OpenSSL places those records on an
unprocessed records queue. It additionally updates the window immediately,
even though we have not yet verified the MAC. This will only occur if
currently in a handshake/renegotiation.
This could be exploited by an attacker by sending a record for the next
epoch (which does not have to decrypt or have a valid MAC), with a very
large sequence number. This means the right hand edge of the window is
moved very far to the right, and all subsequent legitimate packets are
dropped causing a denial of service.
A similar effect can be achieved during the initial handshake. In this
case there is no MAC key negotiated yet. Therefore an attacker can send a
message for the current epoch with a very large sequence number. The code
will process the record as normal. If the hanshake message sequence number
(as opposed to the record sequence number that we have been talking about
so far) is in the future then the injected message is bufferred to be
handled later, but the window is still updated. Therefore all subsequent
legitimate handshake records are dropped. This aspect is not considered a
security issue because there are many ways for an attacker to disrupt the
initial handshake and prevent it from completing successfully (e.g.
injection of a handshake message will cause the Finished MAC to fail and
the handshake to be aborted). This issue comes about as a result of trying
to do replay protection, but having no integrity mechanism in place yet.
Does it even make sense to have replay protection in epoch 0? That
issue isn't addressed here though.
This addressed an OCAP Audit issue.
CVE-2016-2181
Reviewed-by: Richard Levitte <levitte@openssl.org>
Injects a record from epoch 1 during epoch 0 handshake, with a record
sequence number in the future, to test that the record replay protection
feature works as expected. This is described more fully in the next commit.
Reviewed-by: Richard Levitte <levitte@openssl.org>
During a DTLS handshake we may get records destined for the next epoch
arrive before we have processed the CCS. In that case we can't decrypt or
verify the record yet, so we buffer it for later use. When we do receive
the CCS we work through the queue of unprocessed records and process them.
Unfortunately the act of processing wipes out any existing packet data
that we were still working through. This includes any records from the new
epoch that were in the same packet as the CCS. We should only process the
buffered records if we've not got any data left.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Add a test to inject a record from the next epoch during the handshake and
make sure it doesn't get processed immediately.
Reviewed-by: Richard Levitte <levitte@openssl.org>
We calculate the size required for the ServerKeyExchange message and then
call BUF_MEM_grow_clean() on the buffer. However we fail to take account of
2 bytes required for the signature algorithm and 2 bytes for the signature
length, i.e. we could overflow by 4 bytes. In reality this won't happen
because the buffer is pre-allocated to a large size that means it should be
big enough anyway.
Addresses an OCAP Audit issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
RAND_pseudo_bytes() allows random data to be returned even in low entropy
conditions. Sometimes this is ok. Many times it is not. For the avoidance
of any doubt, replace existing usage of RAND_pseudo_bytes() with
RAND_bytes().
Reviewed-by: Rich Salz <rsalz@openssl.org>
A common idiom in the codebase is:
if (p + len > limit)
{
return; /* Too long */
}
Where "p" points to some malloc'd data of SIZE bytes and
limit == p + SIZE
"len" here could be from some externally supplied data (e.g. from a TLS
message).
The rules of C pointer arithmetic are such that "p + len" is only well
defined where len <= SIZE. Therefore the above idiom is actually
undefined behaviour.
For example this could cause problems if some malloc implementation
provides an address for "p" such that "p + len" actually overflows for
values of len that are too big and therefore p + len < limit!
Issue reported by Guido Vranken.
CVE-2016-2177
Reviewed-by: Rich Salz <rsalz@openssl.org>
The ssl3_digest_cached_records() function was failing to handle errors
that might be returned from EVP_DigestSignInit() and
EVP_DigestSignUpdate().
RT#4180
Reviewed-by: Stephen Henson <steve@openssl.org>
Set ctx->error = X509_V_ERR_OUT_OF_MEM when verificaiton cannot
continue due to malloc failure. Similarly for issuer lookup failures
and caller errors (bad parameters or invalid state).
Also, when X509_verify_cert() returns <= 0 make sure that the
verification status does not remain X509_V_OK, as a last resort set
it it to X509_V_ERR_UNSPECIFIED, just in case some code path returns
an error without setting an appropriate value of ctx->error.
Add new and some missing error codes to X509 error -> SSL alert switch.
Reviewed-by: Tim Hudson <tjh@openssl.org>
If p2 == NULL then p1 can get freed twice and a crash could occur.
Issue reported by Shi Lei (Qihoo 360 Inc)
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Some compression related functions in libssl have dummy versions to be
used when compiled with no-comp. However those dummy functions were not
being exported on Windows so they are unusable when dynamically linked.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Per RFC 5246,
Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand.
Although second sentence would suggest that there would be no interop
problems in always offering the extension, WebRTC has reported issues
with Bouncy Castle on < TLS 1.2 ClientHellos that still include
signature_algorithms. See also
https://bugs.chromium.org/p/webrtc/issues/detail?id=4223
RT#4390
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>
(cherry picked from commit f7aa318552c4ef62d902c480b59bd7c4513c0009)
Conflicts:
ssl/ssl_locl.h
If no serverinfo extension is found in some cases, do not abort the handshake,
but simply omit/skip that extension.
Check for already-registered serverinfo callbacks during serverinfo
registration.
Update SSL_CTX_use_serverinfo() documentation to mention the need to reload the
same serverinfo per certificate, for servers with multiple server certificates.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
The i2d_X509() function can return a negative value on error. Therefore
we should make sure we check it.
Issue reported by Yuan Jochen Kang.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 446ba8de9af9aa4fa3debc7c76a38f4efed47a62)
Free up parsed X509_NAME structure if the CertificateRequest message
contains excess data.
The security impact is considered insignificant. This is a client side
only leak and a large number of connections to malicious servers would
be needed to have a significant impact.
This was found by libFuzzer.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>
* Perform ALPN after the SNI callback; the SSL_CTX may change due to
that processing
* Add flags to indicate that we actually sent ALPN, to properly error
out if unexpectedly received.
* document ALPN functions
* unit tests
Backport of commit 817cd0d52f0462039d1fe60462150be7f59d2002
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
If a call to EVP_DecryptUpdate fails then a memory leak could occur.
Ensure that the memory is freed appropriately.
Issue reported by Guido Vranken.
Reviewed-by: Richard Levitte <levitte@openssl.org>
SSLv2 should be off by default. You can only turn it on if you have called
SSL_CTX_clear_options(SSL_OP_NO_SSLv2) or
SSL_clear_options(SSL_OP_NO_SSLv2). You should not be able to inadvertantly
turn it on again via SSL_CONF without having done that first.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
SSLv2 is by default disabled at build-time. Builds that are not
configured with "enable-ssl2" will not support SSLv2. Even if
"enable-ssl2" is used, users who want to negotiate SSLv2 via the
version-flexible SSLv23_method() will need to explicitly call either
of:
SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
or
SSL_clear_options(ssl, SSL_OP_NO_SSLv2);
as appropriate. Even if either of those is used, or the application
explicitly uses the version-specific SSLv2_method() or its client
or server variants, SSLv2 ciphers vulnerable to exhaustive search
key recovery have been removed. Specifically, the SSLv2 40-bit
EXPORT ciphers, and SSLv2 56-bit DES are no longer available.
Mitigation for CVE-2016-0800
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Previous commit f73c737c7 attempted to "fix" a problem with the way
SSL_shutdown() behaved whilst in mid-handshake. The original behaviour had
SSL_shutdown() return immediately having taken no action if called mid-
handshake with a return value of 1 (meaning everything was shutdown
successfully). In fact the shutdown has not been successful.
Commit f73c737c7 changed that to send a close_notify anyway and then
return. This seems to be causing some problems for some applications so
perhaps a better (much simpler) approach is revert to the previous
behaviour (no attempt at a shutdown), but return -1 (meaning the shutdown
was not successful).
This also fixes a bug where SSL_shutdown always returns 0 when shutdown
*very* early in the handshake (i.e. we are still using SSLv23_method).
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Modified version of the commit ffaef3f15 in the master branch by Stephen
Henson. This makes the SSL_OP_SINGLE_DH_USE option a no-op and always
generates a new DH key for every handshake regardless.
CVE-2016-0701 (fix part 2 or 2)
Issue reported by Antonio Sanso
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Based on patch by: Nimrod Aviram <nimrod.aviram@gmail.com>
CVE-2015-3197
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Calling SSL_shutdown while in init previously gave a "1" response, meaning
everything was successfully closed down (even though it wasn't). Better is
to send our close_notify, but fail when trying to receive one.
The problem with doing a shutdown while in the middle of a handshake is
that once our close_notify is sent we shouldn't really do anything else
(including process handshake/CCS messages) until we've received a
close_notify back from the peer. However the peer might send a CCS before
acting on our close_notify - so we won't be able to read it because we're
not acting on CCS messages!
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Error in the definition of the macro SSL_set1_sigalgs(ctx, slist,
slistlen): the third parameter 'slistlen' not used in the substitution
code; used 'clistlen' instead. As a result of this, compilation error
occurs when any application uses this macro.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
It makes no sense to call the OCSP status callback if we are resuming a
session because no certificates will be sent.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
If a server sends the status_request extension then it may choose
to send the CertificateStatus message. However this is optional.
We were treating it as mandatory and the connection was failing.
Thanks to BoringSSL for reporting this issue.
RT#4120
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Fix some more URLs mangled by indent in the reformat. These ones don't exist
in master so we have a separate commit. Based on a patch supplied by Arnaud
Lacombe <al@aerilon.ca>
Reviewed-by: Richard Levitte <levitte@openssl.org>
A BIO_flush call in the DTLS code was not correctly setting the |rwstate|
variable to SSL_WRITING. This means that SSL_get_error() will not return
SSL_ERROR_WANT_WRITE in the event of an IO retry.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 67f60be8c9ae5ff3129fcd6238baf124385a41d8)
If using DTLS and NBIO then if a second or subsequent handshake message
fragment hits a retry, then the retry attempt uses the wrong fragment
offset value. This commit restores the fragment offset from the last
attempt.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 2ad226e88bee97847496e542d63c67997d5beda6)
If the call to OBJ_find_sigid_by_algs fails to find the relevant NID then
we should set the NID to NID_undef.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 330dcb09b2df7e1e6d1d3d14a5df7269aebd9a68)
The feature_test_macros(7) manual tells us that _BSD_SOURCE is
deprecated since glibc 2.20 and that the compiler will warn about it
being used, unless _DEFAULT_SOURCE is defined as well.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit f9fd35248c9a3b1125d9ab82ffb19d62e86533ac)
In the DTLS ClientHello processing the return value is stored in |ret| which
by default is -1. |ret| is only updated to a positive value once we are past
all points where we could hit an error. We wish to return 1 on success or 2
on success *and* we have validated the DTLS cookie. Previously on successful
validation of the cookie we were setting |ret| to -2, and then once we were
past all error points we set |ret = -ret|. This is non-obvious behaviour and
could be error prone. This commit tries to make this a bit more intuitive.
Reviewed-by: Andy Polyakov <appro@openssl.org>
If somewhere in SSL_new() there is a memory allocation failure, ssl3_free() can
get called with s->s3 still being NULL.
Patch also provided by Willy Tarreau <wtarreau@haproxy.com>
Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>
(cherry picked from commit 3e7bd2ce0b16f8611298175d6dc7cb35ee06ea6d)
