we will support then dtls1_do_write can go into an infinite loop. This commit
fixes that.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit d3d9eef316)
at least the minimum or it will fail.
There were some instances in dtls1_query_mtu where the final mtu can end up
being less than the minimum, i.e. where the user has set an mtu manually. This
shouldn't be allowed. Also remove dtls1_guess_mtu that, despite having
logic for guessing an mtu, was actually only ever used to work out the minimum
mtu to use.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 1620a2e49c)
and instead use the value provided by the underlying BIO. Also provide some
new DTLS_CTRLs so that the library user can set the mtu without needing to
know this constant. These new DTLS_CTRLs provide the capability to set the
link level mtu to be used (i.e. including this IP/UDP overhead). The previous
DTLS_CTRLs required the library user to subtract this overhead first.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 59669b6abf)
Conflicts:
ssl/d1_both.c
mtu that we have received is not less than the minimum. If its less it uses the
minimum instead. The second call to query the mtu does not do that, but
instead uses whatever comes back. We have seen an instance in RT#3592 where we
have got an unreasonably small mtu come back. This commit makes both query
checks consistent.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 6abb0d1f8e)
automatically updated, and we should use the one provided instead.
Unfortunately there are a couple of locations where this is not respected.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 001235778a)
RT#3592 provides an instance where the OPENSSL_assert that this commit
replaces can be hit. I was able to recreate this issue by forcing the
underlying BIO to misbehave and come back with very small mtu values. This
happens the second time around the while loop after we have detected that the
MTU has been exceeded following the call to dtls1_write_bytes.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit cf75017bfd)
In a couple of functions, a sequence number would be calculated twice.
Additionally, in |dtls1_process_out_of_seq_message|, we know that
|frag_len| <= |msg_hdr->msg_len| so the later tests for |frag_len <
msg_hdr->msg_len| can be more clearly written as |frag_len !=
msg_hdr->msg_len|, since that's the only remaining case.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Previously, a truncated DTLS fragment in
|dtls1_process_out_of_seq_message| would cause *ok to be cleared, but
the return value would still be the number of bytes read. This would
cause |dtls1_get_message| not to consider it an error and it would
continue processing as normal until the calling function noticed that
*ok was zero.
I can't see an exploit here because |dtls1_get_message| uses
|s->init_num| as the length, which will always be zero from what I can
see.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
The |pqueue_insert| function can fail if one attempts to insert a
duplicate sequence number. When handling a fragment of an out of
sequence message, |dtls1_process_out_of_seq_message| would not call
|dtls1_reassemble_fragment| if the fragment's length was zero. It would
then allocate a fresh fragment and attempt to insert it, but ignore the
return value, leaking the fragment.
This allows an attacker to exhaust the memory of a DTLS peer.
Fixes CVE-2014-3507
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
In |dtls1_reassemble_fragment|, the value of
|msg_hdr->frag_off+frag_len| was being checked against the maximum
handshake message size, but then |msg_len| bytes were allocated for the
fragment buffer. This means that so long as the fragment was within the
allowed size, the pending handshake message could consume 16MB + 2MB
(for the reassembly bitmap). Approx 10 outstanding handshake messages
are allowed, meaning that an attacker could consume ~180MB per DTLS
connection.
In the non-fragmented path (in |dtls1_process_out_of_seq_message|), no
check was applied.
Fixes CVE-2014-3506
Wholly based on patch by Adam Langley with one minor amendment.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
The |item| variable, in both of these cases, may contain a pointer to a
|pitem| structure within |s->d1->buffered_messages|. It was being freed
in the error case while still being in |buffered_messages|. When the
error later caused the |SSL*| to be destroyed, the item would be double
freed.
Thanks to Wah-Teh Chang for spotting that the fix in 1632ef74 was
inconsistent with the other error paths (but correct).
Fixes CVE-2014-3505
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
A buffer overrun attack can be triggered by sending invalid DTLS fragments
to an OpenSSL DTLS client or server. This is potentially exploitable to
run arbitrary code on a vulnerable client or server.
Fixed by adding consistency check for DTLS fragments.
Thanks to Jüri Aedla for reporting this issue.
(cherry picked from commit 1632ef7448)
Unnecessary recursion when receiving a DTLS hello request can be used to
crash a DTLS client. Fixed by handling DTLS hello request without recursion.
Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue.
(cherry picked from commit d3152655d5)
A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64k of memory to a connected client or
server.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix (CVE-2014-0160)
(cherry picked from commit 96db9023b8)
For DTLS we might need to retransmit messages from the previous session
so keep a copy of write context in DTLS retransmission buffers instead
of replacing it after sending CCS. CVE-2013-6450.
(cherry picked from commit 34628967f1)
Since this is always called from DTLS code it is safe to assume the header
length should be the DTLS value. This avoids the need to check the version
number and should work with any version of DTLS (not just 1.0).
(cherry picked from commit 9cf0f18754)
Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.
Specifically almost all of the record generation functions have code like
this:
some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);
...
write_handshake_message(ssl);
Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.
By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.
(cherry picked from commit 173e72e64c)
Submitted by: Robin Seggelmann <seggelmann@fh-muenster.de>
Reviewed by: steve
Send alert instead of assertion failure for incorrectly formatted DTLS
fragments.
