Full Report
Intro Hello again! It’s been a while since the last blog post. This is due to not having as much time as we wanted but hopefully you all kept the pace with this heapy things as they are easy to forget due to the heavy amount of little details the heap involves. On this post we are going to demonstrate how a single byte overflow, with a user controlled value, can cause chunks to disappear for the implementation like a magician puts a cape on top of objects (chunks) and makes them disappear.
Analysis Summary
# Tool/Technique: 1 Byte Heap Overflow Exploitation (Linux `ptmalloc2`)
## Overview
This document summarizes the techniques detailed in a blog post concerning **Linux Heap Exploitation**, specifically focusing on how a **single-byte overflow** (either direct or null-byte controlled) within a heap buffer can be leveraged to manipulate chunk metadata, causing subsequent heap chunks to be unexpectedly freed or merged, effectively making them "disappear" from the allocator's management structures. This technique relies heavily on manipulating the size fields of adjacent memory chunks.
## Technical Details
- Type: Technique (Memory Corruption Vulnerability Exploitation)
- Platform: Linux (Implied target is due to the mention of `ptmalloc2` and Linux heap concepts)
- Capabilities: Arbitrary manipulation of heap chunk sizes, leading to memory corruption, chunk overlapping, and potential arbitrary write primitives in specific scenarios.
- First Seen: The underlying vulnerability type (heap overflow) is long-standing; specific exploitation scenarios depend on the GLIBC version being targeted (the article is from 2017).
## MITRE ATT&CK Mapping
Since this focuses on a low-level memory corruption technique used to gain control, the most relevant mappings relate to exploitation leading to execution:
- **TA0002 - Execution**
- **T1204.002 - User Execution: Malicious File** (If the vulnerable application is executed by a user)
- **T1059.004 - Command and Scripting Interpreter: Unix Shell** (If the exploitation leads to command execution)
- **TA0004 - Privilege Escalation**
- **T1068 - Exploitation for Privilege Escalation** (Assuming the vulnerable application runs with higher privileges)
## Functionality
### Core Capabilities
The technique centers on two primary scenarios within the context of `ptmalloc2` (the GLIBC malloc implementation):
1. **User-Controlled Byte Overflow (General):** Overwriting the least significant byte of an adjacent chunk's size field. This modification allows an attacker to shrink or expand the perceived size of the following chunk.
* **Goal:** Force chunk merging or allocation sizing to overlap into adjacent metadata or data regions (e.g., Chunk C).
2. **Null Byte Overflow (Single NUL Byte Write):** Overwriting the size field such that the most significant bytes remain untouched, but a trailing null byte changes the size structure (e.g., shrinking 0x250 to 0x200).
* **Goal (Specific Scenario):** By shrinking Chunk B, and subsequently freeing a later chunk (Chunk C), the **unlink** macro is triggered. Because Chunk C's `PREV_SIZE` points back to the now-modified Chunk B, and its `PREV_INUSE` bit is cleared, the allocator merges C with the chunk preceding it (Chunk J), potentially forgetting or corrupting chunks in between (like Chunk K).
### Advanced Features
* **Chunk Size Manipulation:** Directly controlling allocation sizes by modifying existing metadata, leading to buffer overflows into subsequent user data or heap control structures (FD/BK pointers).
* **Double Free Simulation/Unlinking Bypass:** The null-byte scenario directly demonstrates causing chunks (C and J) to merge, thereby causing the allocator to "forget" about intermediate chunks (K), which is a form of heap manipulation often preceding arbitrary write primitives (though the article focuses on the memory consumption aspect).
* **Overlapping Allocations:** By incorrectly setting the size of chunk B based on the overflow, subsequent allocations can intentionally overlap into the memory space designated for Chunk C, allowing controlled data writes into neighboring structures.
## Indicators of Compromise
As this describes a conceptual exploitation technique rather than a deployed piece of malware, traditional IOCs are absent. The "indicators" are related to the execution of the exploit code or the resulting behavior in memory management logic:
- File Hashes: N/A (Exploit memory structure or PoC source code only)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: `nc 178.62.74.135 10000`, `nc 178.62.74.135 10001` (Challenge targets, defanged: `nc hxxp://178.62.74.135 hxxp://10000`, `nc hxxp://178.62.74.135 hxxp://10001`)
- Behavioral Indicators:
* Unexpected modification of heap chunk metadata (specifically the `size` field).
* Incorrect merging of free chunks during a `free()` operation due to corrupted `PREV_INUSE` or `PREV_SIZE` fields.
* Allocation return pointers pointing to adjacent, unallocated memory regions (chunk overlap).
## Associated Threat Actors
None directly associated with this specific write-up, as it is a didactic/educational post demonstrating vulnerability exploitation techniques prevalent in Linux environments.
## Detection Methods
Detection focuses on identifying the prerequisite condition (buffer overflow) or the resulting anomalous memory operations:
- Signature-based detection: Not feasible for a conceptual technique unless specific exploit payloads used in CTFs/PoCs are cataloged.
- Behavioral detection: Monitoring applications for overly large memory writes originating from user-controlled input buffers that exceed expected allocation boundaries. Heap instrumentation tools (like AddressSanitizer or heap debuggers) would flag metadata corruption immediately.
- YARA rules: N/A
## Mitigation Strategies
The core mitigation relies on preventing the initial buffer overflow and ensuring heap integrity:
- Prevention measures: Utilizing safer memory allocation and boundary checking libraries, or migrating to memory-safe languages where possible.
- Hardening recommendations:
* Employing modern, hardened GLIBC versions that include checks against dangerous list operations (like safe unlinking, though the techniques described predate or circumvent some standard mitigations).
* Statically checking array sizes and allocation lengths before performing memory copies (e.g., using `strncpy` or ensuring inputs fit bounds).
* Compiling code with strong stack/heap protections (e.g., non-executable stacks/heaps, Address Space Layout Randomization (ASLR)).
## Related Tools/Techniques
* **Use-After-Free (UAF):** Mentioned in the context of the prior blog post in the series (`use-after-free`).
* **General Heap Corruption/Metadata Manipulation:** Techniques like **House of Lore**, **House of Spirit**, and **Fastbin Corruption** exploit similar heap structure vulnerabilities.
* **Poisoned NUL Byte:** Referenced in the external links, a closely related technique where a single null byte is used to alter string sizing or pointer values stored near the boundary.