so whats the issue? lets look in to the patched code:
if you look at the checks there are following checks:
1. if (1 + 2 + 16 > s->s3->rrec.length)
return 0; /* silently discard */
2.if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0; /* silently discard per RFC 6520 sec. 4 */
3.if (write_length > SSL3_RT_MAX_PLAIN_LENGTH)
return 0;
first check make sure that it discard the packets where TLS length is less then 19 bytes. why? its because 1 byte denote msg type, 2 bytes denote length and 16 bytes is padding. so this will discard packet with 0 payload length.
second check will make sure that length of payload + header is equal to length mentioned in TLS packet.
third check will make sure that write length is not more then 16348 or 0x4000 which is SSL3_RT_MAX_PLAIN_LENGTH.
This is a quick post and hope it clarifies the things. if you have any questions feel free to mail me.
HeartBleed Vulnerability, CVE-2014-0160 Analysis
Table of Contents
so whats the issue? lets look in to the patched code:
if you look at the checks there are following checks:
1. if (1 + 2 + 16 > s->s3->rrec.length)
return 0; /* silently discard */
2.if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0; /* silently discard per RFC 6520 sec. 4 */
3.if (write_length > SSL3_RT_MAX_PLAIN_LENGTH)
return 0;
first check make sure that it discard the packets where TLS length is less then 19 bytes. why? its because 1 byte denote msg type, 2 bytes denote length and 16 bytes is padding. so this will discard packet with 0 payload length.
second check will make sure that length of payload + header is equal to length mentioned in TLS packet.
third check will make sure that write length is not more then 16348 or 0x4000 which is SSL3_RT_MAX_PLAIN_LENGTH.
This is a quick post and hope it clarifies the things. if you have any questions feel free to mail me.
Tags:
FUZZING.IN