Report

CVE-2014-0160 Heartbleed: Unsanitized Payload Length in TLS Heartbeat Processing

de29a601-1978-4880-be94-f07a9e0dbe7b

The TLS heartbeat extension in OpenSSL 1.0.1 through 1.0.1f contains a critical out-of-bounds read vulnerability (CVE-2014-0160, known as Heartbleed). The vulnerability exists in the tls1_process_heartbeat() function which processes incoming TLS heartbeat requests. The function reads a 2-byte payload length directly from untrusted client-supplied data and uses this unsanitized length value to determine how many bytes to copy from a buffer, without verifying that the actual received data contains that many bytes. This allows an attacker to read arbitrary amounts of server memory by claiming a large payload length in a small heartbeat packet, causing the server to leak sensitive data including private keys, session tokens, and other confidential information.",antml:parameter> Located the vulnerability by: 1) Searching for tls1_process_heartbeat function definition in ssl/t1_lib.c at line 2554. 2) Analyzing the function flow: Line 2563 uses n2s(p, payload) to read a 2-byte user-supplied length without validation. 3) Line 2580 allocates buffer using this untrusted payload value. 4) Line 2586 performs memcpy(bp, pl, payload) without bounds checking. 5) Examined SSL3_RECORD structure to understand that s->s3->rrec.length contains actual received bytes but is never compared against payload. The entire received heartbeat packet may be only 3-4 bytes (type + length header + minimal payload), but the code will copy whatever length the attacker claims.",antml:parameter> The vulnerability should be fixed by validating the payload length before the memcpy operation. A proper fix would check: if (payload > s->s3->rrec.length - 3) { reject/return error; }. This ensures the payload length does not exceed the actual received record data (minus the 1-byte type and 2-byte length header). Additionally, implementing stricter bounds checking throughout the heartbeat processing would prevent similar issues. OpenSSL fixed this in version 1.0.1g (released April 7, 2014) by adding a length validation check that ensures the payload does not exceed the received record length.",antml:parameter> The vulnerability is confirmed by the complete absence of any bounds checking between lines 2563 (where payload is read from attacker-controlled data) and 2586 (where memcpy uses this unsanitized value). The actual record length available in s->s3->rrec.length is available and should be compared against payload, but this comparison never occurs in the vulnerable code.",antml:parameter> Out-of-Bounds Read (Heartbleed)",antml:parameter> out-of-bounds-read",antml:parameter> missing_dependency",antml:parameter> critical",antml:parameter> c",antml:parameter> {"OpenSSL": "1.0.1f"}},antml:parameter> ["heartbleed", "CVE-2014-0160", "out-of-bounds-read", "TLS", "memory-leak", "OpenSSL", "cold-baseline"]