Revision f5c7f5dfbaf0d2f7d946d0fe86f08e6bcb36ed0d authored by Matt Caswell on 30 June 2016, 12:17:08 UTC, committed by Matt Caswell on 22 August 2016, 09:53:55 UTC
DTLS can handle out of order record delivery. Additionally since handshake messages can be bigger than will fit into a single packet, the messages can be fragmented across multiple records (as with normal TLS). That means that the messages can arrive mixed up, and we have to reassemble them. We keep a queue of buffered messages that are "from the future", i.e. messages we're not ready to deal with yet but have arrived early. The messages held there may not be full yet - they could be one or more fragments that are still in the process of being reassembled. The code assumes that we will eventually complete the reassembly and when that occurs the complete message is removed from the queue at the point that we need to use it. However, DTLS is also tolerant of packet loss. To get around that DTLS messages can be retransmitted. If we receive a full (non-fragmented) message from the peer after previously having received a fragment of that message, then we ignore the message in the queue and just use the non-fragmented version. At that point the queued message will never get removed. Additionally the peer could send "future" messages that we never get to in order to complete the handshake. Each message has a sequence number (starting from 0). We will accept a message fragment for the current message sequence number, or for any sequence up to 10 into the future. However if the Finished message has a sequence number of 2, anything greater than that in the queue is just left there. So, in those two ways we can end up with "orphaned" data in the queue that will never get removed - except when the connection is closed. At that point all the queues are flushed. An attacker could seek to exploit this by filling up the queues with lots of large messages that are never going to be used in order to attempt a DoS by memory exhaustion. I will assume that we are only concerned with servers here. It does not seem reasonable to be concerned about a memory exhaustion attack on a client. They are unlikely to process enough connections for this to be an issue. A "long" handshake with many messages might be 5 messages long (in the incoming direction), e.g. ClientHello, Certificate, ClientKeyExchange, CertificateVerify, Finished. So this would be message sequence numbers 0 to 4. Additionally we can buffer up to 10 messages in the future. Therefore the maximum number of messages that an attacker could send that could get orphaned would typically be 15. The maximum size that a DTLS message is allowed to be is defined by max_cert_list, which by default is 100k. Therefore the maximum amount of "orphaned" memory per connection is 1500k. Message sequence numbers get reset after the Finished message, so renegotiation will not extend the maximum number of messages that can be orphaned per connection. As noted above, the queues do get cleared when the connection is closed. Therefore in order to mount an effective attack, an attacker would have to open many simultaneous connections. Issue reported by Quan Luo. CVE-2016-2179 Reviewed-by: Richard Levitte <levitte@openssl.org>
1 parent 5dfd038
README.ECC
NOTE: The OpenSSL Software Foundation has executed a sublicense agreement
entitled "Elliptic Curve Cryptography Patent License Agreement" with the
National Security Agency/ Central Security Service Commercial Solutions
Center (NCSC) dated 2010-11-04. That agreement permits implementation and
distribution of software containing features covered by any or all of the
following patents:
1.) U.S. Pat. No. 5,761,305 entitled "Key Agreement and Transport Protocol
with Implicit Signatures" issued on June 2, 1998;
2.) Can. Pat. Appl. Ser. No. 2176972 entitled "Key Agreement and Transport
Protocol with Implicit Signature and Reduced Bandwidth" filed on May
16, 1996;
3.) U.S. Pat. No. 5,889,865 entitled "Key Agreement and Transport Protocol
with Implicit Signatures" issued on March 30, 1999;
4.) U.S. Pat. No. 5,896,455 entitled "Key Agreement and Transport Protocol
with Implicit Signatures" issued on April 20, 1999;
5.) U.S. Pat. No. 5,933,504 entitled "Strengthened Public Key Protocol"
issued on August 3, 1999;
6.) Can. Pat. Appl. Ser. No. 2176866 entitled "Strengthened Public Key
Protocol" filed on May 17, 1996;
7.) E.P. Pat. Appl. Ser. No. 96201322.3 entitled "Strengthened Public Key
Protocol" filed on May 17, 1996;
8.) U.S. Pat. No. 5,999,626 entitled "Digital Signatures on a Smartcard"
issued on December 7, 1999;
9.) Can. Pat. Appl. Ser. No. 2202566 entitled "Digital Signatures on a
Smartcard" filed on April 14, 1997;
10.) E.P. Pat. Appl. No. 97106114.8 entitled "Digital Signatures on a
Smartcard" filed on April 15, 1997;
11.) U.S Pat. No. 6,122,736 entitled "Key Agreement and Transport Protocol
with Implicit Signatures" issued on September 19, 2000;
12.) Can. Pat. Appl. Ser. No. 2174261 entitled "Key Agreement and Transport
Protocol with Implicit Signatures" filed on April 16, 1996;
13.) E.P. Pat. Appl. Ser. No. 96105920.1 entitled "Key Agreement and
Transport Protocol with Implicit Signatures" filed on April 16, 1996;
14.) U.S. Pat. No. 6,141,420 entitled "Elliptic Curve Encryption Systems"
issued on October 31, 2000;
15.) Can. Pat. Appl. Ser. No. 2155038 entitled "Elliptic Curve Encryption
Systems" filed on July 31, 1995;
16.) E.P. Pat. Appl. Ser. No. 95926348.4 entitled "Elliptic Curve Encryption
Systems" filed on July 31, 1995;
17.) U.S. Pat. No. 6,336,188 entitled "Authenticated Key Agreement" issued
on January 1, 2002;
18.) U.S. Pat. No. 6,487,661 entitled "Key Agreement and Transport Protocol"
issued on November 26, 2002;
19.) Can. Pat. Appl. Ser. No. 2174260 entitled "Key Agreement and Transport
Protocol" filed on April 16, 1996;
20.) E.P. Pat. Appl. Ser. No. 96105921.9 entitled "Key Agreement and
Transport Protocol" filed on April 21, 1996;
21.) U.S. Pat. No. 6,563,928 entitled "Strengthened Public Key Protocol"
issued on May 13, 2003;
22.) U.S. Pat. No. 6,618,483 entitled "Elliptic Curve Encryption Systems"
issued September 9, 2003;
23.) U.S. Pat. Appl. Ser. No. 09/434,247 entitled "Digital Signatures on a
Smartcard" filed on November 5, 1999;
24.) U.S. Pat. Appl. Ser. No. 09/558,256 entitled "Key Agreement and
Transport Protocol with Implicit Signatures" filed on April 25, 2000;
25.) U.S. Pat. Appl. Ser. No. 09/942,492 entitled "Digital Signatures on a
Smartcard" filed on August 29, 2001 and published on July 18, 2002; and,
26.) U.S. Pat. Appl. Ser. No. 10/185,735 entitled "Strengthened Public Key
Protocol" filed on July 1, 2000.
Computing file changes ...
