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 |
|---|---|---|
| MS | -rw-r--r-- | 166 bytes |
| SSLv3 | -rw-r--r-- | 2.4 KB |
| alpha.c | -rw-r--r-- | 3.7 KB |
| dggccbug.c | -rw-r--r-- | 926 bytes |
| sgiccbug.c | -rw-r--r-- | 1.3 KB |
| sslref.dif | -rw-r--r-- | 1.1 KB |
| stream.c | -rw-r--r-- | 4.5 KB |
| ultrixcc.c | -rw-r--r-- | 584 bytes |
Computing file changes ...
