Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Ensure RAND_bytes return value is checked correctly, and that we no longer
use RAND_pseudo_bytes.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Ensure that all functions have their return values checked where
appropriate. This covers all functions defined and called from within
libssl.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
from dtls1_buffer_message() which was needed to distinguish between DTLS
1.x and Cisco's pre-standard version of DTLS (DTLS1_BAD_VER).

Based on an original patch by David Woodhouse <dwmw2@infradead.org>
RT#3703
Reviewed-by: NTim Hudson <tjh@openssl.org>

I left many "#if 0" lines, usually because I thought we would
probably want to revisit them later, or because they provided
some useful internal documentation tips.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

This should be a one off operation (subsequent invokation of the
script should not move them)
Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

Sometimes it fails to format them very well, and sometimes it corrupts them!
This commit moves some particularly problematic ones.
Reviewed-by: NTim Hudson <tjh@openssl.org>

indent will not alter them when reformatting comments
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

we will support then dtls1_do_write can go into an infinite loop. This commit
fixes that.
Reviewed-by: NTim Hudson <tjh@openssl.org>

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: NTim Hudson <tjh@openssl.org>

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: NTim Hudson <tjh@openssl.org>

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: NTim Hudson <tjh@openssl.org>

automatically updated, and we should use the one provided instead.
Unfortunately there are a couple of locations where this is not respected.
Reviewed-by: NTim Hudson <tjh@openssl.org>

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: NTim Hudson <tjh@openssl.org>

PR#3608
Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

Add a dozen more const declarations where appropriate.
These are from Justin; while adding his patch, I noticed
ASN1_BIT_STRING_check could be fixed, too.
Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

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: NMatt Caswell <matt@openssl.org>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Applying same fix as in dtls1_process_out_of_seq_message. A truncated DTLS fragment would cause *ok to be clear, but the return value would still be the number of bytes read.

Problem identified by Emilia Käsper, based on previous issue/patch by Adam
Langley.
Reviewed-by: NEmilia 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: NMatt Caswell <matt@openssl.org>
Reviewed-by: NEmilia 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: NMatt Caswell <matt@openssl.org>
Reviewed-by: NEmilia 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: NEmilia Käsper <emilia@openssl.org>

Reviewed-by: NEmilia 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: NMatt Caswell <matt@openssl.org>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

PR#3394

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 1632ef744872edc2aa2a53d487d3e79c965a4ad3)

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 d3152655d5319ce883c8e3ac4b99f8de4c59d846)

PR#3302

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 96db9023b881d7cd9f379b0c154650d6c108e9a3)

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 34628967f1e65dc8f34e000f0f5518e21afbfc7b)

Port TLS 1.2 GCM code to DTLS. Enable use of TLS 1.2 only ciphers when in
DTLS 1.2 mode too.

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).

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.

Note: although this passes "make test" and some simple DTLS tests there may
be some minor differences in the DTLS code that have to be accounted for.