Out-of-bounds Read

Description

An out-of-bounds read occurs when software accesses memory outside the boundaries of a buffer, array, or similar data structure, reading data it wasn't intended to see.

Extended Description

This vulnerability happens when a program uses an incorrect index, offset, or pointer that references a memory location before the start or after the end of a valid buffer. For example, using `buffer[size]` or `buffer[-1]` triggers this issue. The result is that the application reads data from adjacent memory locations, which could be uninitialized, contain sensitive information from other parts of the program, or even cause a crash. While this flaw doesn't directly allow data modification like its 'write' counterpart, it remains a serious security risk. Attackers can exploit it to leak sensitive information, bypass security controls, or gather data to enable further attacks. It's a common root cause for information disclosure and is often the first step in more complex exploit chains.

Common Consequences 4

Scope: Confidentiality

Impact: Read Memory

An attacker could get secret values such as cryptographic keys, PII, memory addresses, or other information that could be used in additional attacks.

Scope: Confidentiality

Impact: Bypass Protection Mechanism

Out-of-bounds memory could contain memory addresses or other information that can be used to bypass ASLR and other protection mechanisms in order to improve the reliability of exploiting a separate weakness for code execution.

Scope: Availability

Impact: DoS: Crash, Exit, or Restart

An attacker could cause a segmentation fault or crash by causing memory to be read outside of the bounds of the buffer. This is especially likely when the code reads a variable amount of data and assumes that a sentinel exists to stop the read operation, such as a NUL in a string.

Scope: Other

Impact: Varies by Context

The read operation could produce other undefined or unexpected results.

Detection Methods 2

FuzzingHigh

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Automated Static AnalysisHigh

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Potential Mitigations 2

Phase: Implementation

Strategy: Input Validation

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.

Phase: Architecture and Design

Strategy: Language Selection

Use a language that provides appropriate memory abstractions.

Demonstrative Examples 2

ID : DX-100

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

Code Example:

Bad

// check that the array index is less than the maximum*

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 (Numeric Range Comparison Without Minimum Check). 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 (Buffer Under-read) 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 (Improper Validation of Array Index). In this example the if statement should be modified to include a minimum range check, as shown below.

Code Example:

Good

// check that the array index is within the correct*

ID : DX-91

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.

Code Example:

Bad

// get message from socket and store into buffer*

// process message* success = processMessage(message);} return success;}

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 (Unchecked Input for Loop Condition). If msgLength indicates a length that is longer than the size of a message body (Improper Handling of Length Parameter Inconsistency), then this can result in a buffer over-read by reading past the end of the buffer (Buffer Over-read).

Observed Examples 14

CVE-2023-1018The reference implementation code for a Trusted Platform Module does not implement length checks on data, allowing for an attacker to read 2 bytes past the end of a buffer.

CVE-2020-11899Out-of-bounds read in IP stack used in embedded systems, as exploited in the wild per CISA KEV.

CVE-2014-0160Chain: "Heartbleed" bug receives an inconsistent length parameter (Improper Handling of Length Parameter Inconsistency) enabling an out-of-bounds read (Buffer Over-read), returning memory that could include private cryptographic keys and other sensitive data.

CVE-2021-40985HTML conversion package has a buffer under-read, allowing a crash

CVE-2018-10887Chain: unexpected sign extension (Unexpected Sign Extension) leads to integer overflow (Integer Overflow or Wraparound), causing an out-of-bounds read (Out-of-bounds Read)

CVE-2009-2523Chain: product does not handle when an input string is not NULL terminated (Improper Null Termination), leading to buffer over-read (Out-of-bounds Read) or heap-based buffer overflow (Heap-based Buffer Overflow).

CVE-2018-16069Chain: series of floating-point precision errors (Insufficient Precision or Accuracy of a Real Number) in a web browser rendering engine causes out-of-bounds read (Out-of-bounds Read), giving access to cross-origin data

CVE-2004-0112out-of-bounds read due to improper length check

CVE-2004-0183packet with large number of specified elements cause out-of-bounds read.

CVE-2004-0221packet with large number of specified elements cause out-of-bounds read.

CVE-2004-0184out-of-bounds read, resultant from integer underflow

CVE-2004-1940large length value causes out-of-bounds read

CVE-2004-0421malformed image causes out-of-bounds read

CVE-2008-4113OS kernel trusts userland-supplied length value, allowing reading of sensitive information

References 3

Breaking the memory secrecy assumption

Raoul Strackx, Yves Younan, Pieter Philippaerts, Frank Piessens, Sven Lachmund, and Thomas Walter

ACM

31-03-2009

https://dl.acm.org/doi/10.1145/1519144.1519145(2023-04-07)

ID: REF-1034

The info leak era on software exploitation

Fermin J. Serna

25-07-2012

https://media.blackhat.com/bh-us-12/Briefings/Serna/BH_US_12_Serna_Leak_Era_Slides.pdf

ID: REF-1035

24 Deadly Sins of Software Security

Michael Howard, David LeBlanc, and John Viega

McGraw-Hill

2010

ID: REF-44

Applicable Platforms

Languages:

C : UndeterminedC++ : Undetermined

Technologies:

ICS/OT : Often

Modes of Introduction

Implementation

Related Attack Patterns

540
Inclusion of Sensitive Information in Source Code

Alternate Terms

OOB read

Shorthand for "Out of bounds" read

Functional Areas

Memory Management

Affected Resources

Memory

Related Weaknesses

ChildOf:

Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)

ChildOf:

Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)

ChildOf:

Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)

ChildOf:

Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)

Taxonomy Mapping

PLOVER
CERT C Secure Coding
CERT C Secure Coding
CERT C Secure Coding
CERT C Secure Coding
CERT C Secure Coding
Software Fault Patterns