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
ultrixcc.c
#include <stdio.h>
/* This is a cc optimiser bug for ultrix 4.3, mips CPU.
* What happens is that the compiler, due to the (a)&7,
* does
* i=a&7;
* i--;
* i*=4;
* Then uses i as the offset into a jump table.
* The problem is that a value of 0 generates an offset of
* 0xfffffffc.
*/
main()
{
f(5);
f(0);
}
int f(a)
int a;
{
switch(a&7)
{
case 7:
printf("7\n");
case 6:
printf("6\n");
case 5:
printf("5\n");
case 4:
printf("4\n");
case 3:
printf("3\n");
case 2:
printf("2\n");
case 1:
printf("1\n");
#ifdef FIX_BUG
case 0:
;
#endif
}
}
Computing file changes ...
