CVE-2014-3511

Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Bodo Möller <bodo@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: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia 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: 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>

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>

(cherry picked from commit 27131fe8

)
Reviewed-by: Matt Caswell <matt@openssl.org>

(which didn't always handle value 0 correctly).

Reviewed-by:  <emilia@openssl.org>

Conflicts:
	CHANGES
	crypto/ec/ectest.c

PR#2569

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit cba11f57)

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 62352b81)

statement of opinion rather than a fact.

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit c8d133e4)

PR#1675
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 197400c3f0d617d71ad8167b52fb73046d334320)

PR#3456
Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit d48e78f0)

Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 3bd54819)

PR#3452
(cherry picked from commit ca2015a6)

Use same logic when determining when to expect a client
certificate for both TLS and DTLS.

PR#3452
(cherry picked from commit c8d710dc)

PR#3449
(cherry picked from commit 2054eb77)

The options which emulate a web server don't make sense when doing DTLS.
Exit with an error if an attempt is made to use them.

PR#3453
(cherry picked from commit 58a2aaeade8bdecd0f9f0df41927f7cff3012547)

PR#3445
(cherry picked from commit 1c3e9a7c)

(cherry picked from commit 7aabd9c92fe6f0ea2a82869e5171dcc4518cee85)

This is actually ok for this function, but initialised to zero anyway if
PURIFY defined.

This does have the impact of masking any *real* unitialised data reads in bn though.

Patch based on approach suggested by Rich Salz.

PR#3415

(cherry picked from commit 77747e2d9a5573b1dbc15e247ce18c03374c760c)

PR#3440
(cherry picked from commit 924e5eda)

Conflicts:

	ssl/ssl_ciph.c

  Detected by dcruette@qualitesys.com

(cherry picked from commit 8b5dd340)

Based on an original patch by Neitrino Photonov <neitrinoph@gmail.com>

PR#3439

(cherry picked from commit 66816c53)

PR#2985
(cherry picked from commit 9d23f422)

(cherry picked from commit a07f514f)

Conflicts:

	doc/apps/s_client.pod
	doc/apps/s_server.pod
(cherry picked from commit b197c770)

(cherry picked from commit a23a6e85)

PR#2277
(cherry picked from commit 733a6c882e92f8221bd03a51643bb47f5f81bb81)

(cherry picked from commit 07255f0a76d9d349d915e14f969b9ff2ee0d1953)

PR#3418.
(cherry picked from commit fdea4fff)

PR#319 (reoponed version).
(cherry picked from commit 7f6e9578)

Conflicts:

	ssl/s3_srvr.c

(cherry picked from commit 55707a36)

(cherry picked from commit 2cfbec1c)
(cherry picked from commit a9661e45)

(cherry picked from commit f1112985)