CWE-125: Out-of-bounds Read

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Architecture and Design

Strategy: Language Selection

Class: Memory-Unsafe (Undetermined Prevalence)

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method

However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value ( CWE-839 ). This will allow a negative value to be accepted as the input array index, which will result in reading data before the beginning of the buffer ( CWE-127 ) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array ( CWE-129 ). In this example the if statement should be modified to include a minimum range check, as shown below.

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

However, the message length variable (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body ( CWE-606 ). If msgLength indicates a length that is longer than the size of a message body ( CWE-130 ), then this can result in a buffer over-read by reading past the end of the buffer ( CWE-126 ).

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.