You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: c/secure-coding-case-study-cwe-125-cve-2014-0160.md
+19-19Lines changed: 19 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,28 +1,28 @@
1
1
# OUT-OF-BOUNDS READ IN OPENSSL
2
2
3
-
###Introduction:
3
+
## Introduction
4
4
5
5
C is a memory-unsafe language (it does not prevent invalid memory accesses by default), so if a memory access check is missing or incorrectly performed, an adversary might be able to read information they are not authorized to receive. Failing to restrict reading to the valid range of a memory buffer is called "Out-of-Bounds-Read" and is routinely in the CWE™ Top 25 Most Dangerous Software Weaknesses. OpenSSL is a widely-used cryptographic library. This case study looks at the Heartbleed vulnerability, a critical security flaw in OpenSSL in where adversaries were allowed to request information (a "read") beyond the range of a memory buffer that was stored in a region of memory called the "heap".
The fundamental weakness in this case study is when software reads data outside the intended memory buffer (typically beyond its end) because it trusted attacker-supplied data in a way that permitted referencing memory locations after the targeted buffer.
18
18
19
19
The typical cause of this problem is that the attacker provides data that indicates, to the receiving system, that it should read memory beyond the end of the memory buffer. For example, it may provide a "message length" that does not accurately reflect the actual length, but instead requests a much larger length to be read (this was the cause of the Heartbleed vulnerability).
20
20
21
21
By reading out-of-bounds memory, an attacker might be able to directly obtain unauthorized secret values, such as cryptographic secrets, session keys, or passwords. An attacker might also be able to acquire memory addresses which can in some cases bypass protection mechanisms such as ASLR.
22
22
23
-
###Vulnerability:
23
+
## Vulnerability
24
24
25
-
<ahref="https://www.cve.org/CVERecord?id=CVE-2014-0160">CVE-2014-0160</a> – Published 07 April 2014
25
+
[CVE-2014-0160](https://www.cve.org/CVERecord?id=CVE-2014-0160) – Published 07 April 2014
26
26
27
27
The Heartbleed vulnerability in versions 1.0.1 through 1.0.1f (inclusive) of OpenSSL involved incorrect handling of a "heartbeat" request. OpenSSL implements the TLS protocol for security. An optional feature of the protocol is a "heartbeat" request, where the requester provides can provide a string and its length, and the system is to respond with the same string of that length. Unfortunately, an attacker could provide a string and claim an excessively-long length of the string being provided. When a vulnerable version of OpenSSL received a heartbeat request from the network, it failed to verify that the requested length of the payload matched the length of the data provided (CWE-126) as was required by the specification. As a result, it would reply with additional data beyond the intended memory buffer. Since OpenSSL is a cryptographic library, this other data often had secrets such as private keys, session ids, and passwords.
To exploit this vulnerability one merely needed to send a specially-crafted heartbeat request with a requested length with a small payload (e.g., 1 byte) and far longer payload length (e.g., 65,535 bytes). The vulnerable server using OpenSSL, because it unwisely trusted the claimed length, would respond by copying the provided payload provided by many bytes from its memory containing unauthorized data, then send that response. Authentication was *not* required to trigger this vulnerability, as a heartbeat request did not require user authentication.
84
84
85
85
If that unauthorized data in the response was sensitive, the attacker would then receive that sensitive data. Unfortunately, because the memory is leaked from the heap region of memory, and was often data managed by OpenSSL, it often contained extremely sensitive data such as private keys, passwords, and so on.
86
86
87
87
In addition, the attack is silent, leaving no trace in standard logs. This made it an attack with a potentially high impact and low detectability.
88
88
89
-
###Fix:
89
+
## Fix
90
90
91
-
Let's examine the code commit which fixed the Heartbleed vulnerability. The code adds checks on lines 1339-1340 and lines 1343-1344 to make sure the record will be long enough to store *any* reply, and if not, the request will be silently discarded. These check follow [RFC 6520 section 4](https://datatracker.ietf.org/doc/html/rfc6520) which says that "If the `payload_length` of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently". Previously this wasn't checked. Then lines 1350-1352 were added to accurately compute the `write_length` and that accurate calculation was used on lines 1362 and 1373 as the length to write.
91
+
Let's examine the code commit which fixed the Heartbleed vulnerability. The code adds checks on lines 1339-1340 and lines 1343-1344 to make sure the record will be long enough to store *any* reply, and if not, the request will be silently discarded. These checks follow [RFC 6520 section 4](https://datatracker.ietf.org/doc/html/rfc6520) which says that "If the `payload_length` of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently". Previously this wasn't checked. Then lines 1350-1352 were added to accurately compute the `write_length` and that accurate calculation was used on lines 1362 and 1373 as the length to write.
In this case, Google found the vulnerability through careful human review, while Codenomicon found the vulnerability through an advanced fuzzing technique carefully crafted to find subtle defects. Once the defect was found, the source code was easily fixed. However, the Heartbleed vulnerability was found after the code was released, causing massive headaches worldwide as organizations worked to find vulnerable versions and update them. We want to find vulnerabilities *before* they are released.
149
149
@@ -173,11 +173,11 @@ Other actions could reduce the risk of vulnerabilities like Heartbleed:
173
173
174
174
The online lab exercise [oob1](https://best.openssf.org/labs/oob1.html), part of the online course [Developing Secure Software (LFD121)](https://training.linuxfoundation.org/training/developing-secure-software-lfd121/), provides hands-on experience in fixing the Heartbleed vulnerability.
175
175
176
-
###Conclusion:
176
+
## Conclusion
177
177
178
178
The addition of checks to ensure the requested length did not exceed the data provided (as required), and ensuring that only the valid provided data was returned, eliminated the weakness CWE-125: Out-of-bounds Read. With the weakness resolved, requesters could no longer receive data they weren't authorized to receive, and the Heartbleed vulnerability CVE-2014-0160 was eliminated.
0 commit comments