Revision fc7804ec392fcf8051abe6bc9da9108744d2ae35 authored by Matt Caswell on 06 June 2014, 21:25:52 UTC, committed by Matt Caswell on 06 August 2014, 19:27:51 UTC
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>
1 parent e7b9d9b
File | Mode | Size |
---|---|---|
.cvsignore | -rw-r--r-- | 43 bytes |
Makefile | -rw-r--r-- | 1.2 KB |
c89.sh | -rwxr-xr-x | 211 bytes |
c_hash | -rw-r--r-- | 119 bytes |
c_info | -rw-r--r-- | 152 bytes |
c_issuer | -rw-r--r-- | 112 bytes |
c_name | -rw-r--r-- | 110 bytes |
c_rehash.in | -rw-r--r-- | 4.1 KB |

Computing file changes ...