Full Report
Scudo is a hardened heap allocator that has the goal of preventing heap-based vulnerability classes. It is the default allocator for Android now-a-days. This article breaks down how the allocator works and the protections in place. First, they go over the primary allocator then through the secondary allocator, which are all chunks larger than 0x10010 that are allocated via mmap() directly. Scudo is made up of blocks. The blocks are compromised of a header and a chunk. The chunk is the actual data while the header contains metadata and size information. The allocations are done in regions; blocks of all the same size. Region 0 keeps track of a list of storage pointers within freelists. Between these regions are guard pages to prevent cross-region corruption The allocator randomizes which blocks are returned from a given region. This makes exploitation harder because heap grooming becomes much more difficult. However, the authors note that there are ways to make it more reproducible in certain situations. When freeing a block, verification is done on the header and the pointer that is returned. Once it's freed, the block enters a quarantine process to make the exploitation of UAFs harder. For heap overflows we can mess with the header bytes. However, the verification of the chunk occurs on free() are quite strict. So, exploit developers can either create fake valid headers or simply not let the chunk go through free via the exploit plan. Standard double frees are detected by the bits within the header of the chunk. However, free-reallocate-free is not caught at all. Use after frees are not caught either; although, there is the protection of the quarantine period. Overall, good post on the allocator. I didn't put every single detail into this write up but put my important points and just wanted the page as a reference.
Analysis Summary
# Tool/Technique: Scudo Hardened Allocator
## Overview
Scudo is a hardened dynamic user-mode memory allocator (heap allocator) designed to mitigate against various heap-based vulnerabilities, such as heap-based buffer overflows, Use-After-Free (UAF), and double frees. It is the default allocator for modern Android versions (since Android 11). Its primary goal is to provide resilience against heap exploits while maintaining performance.
## Technical Details
- Type: Tool (Memory Allocator / Mitigation Technique)
- Platform: Android (Primarily discussed in the context of Android 13 on ARM 64-bit architecture)
- Capabilities: Heap memory management, randomization of allocations, header verification, block quarantining, and mitigation against common heap corruption primitives.
- First Seen: N/A (Integrated as default in Android since version 11)
## MITRE ATT&CK Mapping
Since Scudo is a defensive measure implemented within the operating system's library, it relates to defenders preventing exploitation rather than an attacker's tool. However, the techniques it targets and aims to mitigate are mapped below:
- **Defense Evasion:** Some advanced exploitation techniques might attempt to bypass Scudo's randomization.
- **Impact:** Successful exploitation of vulnerabilities *not* fully mitigated by Scudo leads to system compromise.
*Note: Direct mapping for defensive mechanisms like allocators is challenging as ATT&CK focuses on adversary TTPs. The following maps the *vulnerabilities* Scudo mitigates.*
- **[T1592 - Obtain Capabilities/Components]** (If an actor targets Scudo itself)
- **[T1592.003 - Software Discovery]** (Discovering allocator behavior for exploitation)
- **[T1484 - Domain Trust Manipulation]** (If heap corruption leads to privilege escalation which might involve trust manipulation, though this is indirect)
- *Implied Tactic: Persistence/Privilege Escalation if corruption is exploited*
## Functionality
### Core Capabilities
* **Primary/Secondary Allocation:** Divides memory management into two parts: a primary allocator for chunks smaller than `0x10010` bytes, and a secondary allocator (utilizing `mmap()`) for larger allocations.
* **Block Structure:** Memory management units are called **Blocks**, composed of a metadata **Header** (0x10 bytes) and the user data **Chunk**.
* **Region Management:** Allocations of the same size class (`ClassId`) are grouped into contiguous memory zones called **Regions**. Guard pages exist between regions to prevent cross-region corruption.
* **Randomization:** The allocator randomizes which physical blocks are returned from a given region, making heap grooming for predictable exploitation significantly harder.
* **Header Verification:** Strict verification checks are performed on the chunk header during the `free()` operation to detect tampering from overflows.
### Advanced Features
* **Use-After-Free (UAF) Mitigation:** Freed blocks enter a **quarantine process** before reuse, increasing the difficulty of exploiting UAF conditions.
* **Double Free Detection:** Standard double free attempts are detected by checking specific bits within the chunk header.
* **Reproducibility Limitations:** While randomization makes exploitation difficult, the authors note that certain conditions allow for making the allocation returns more reproducible.
* **Vulnerability Limitations:** The analysis notes that the `free-reallocate-free` sequence is **not** caught, and UAFs are only mitigated by the quarantine period, not outright prevention upon access.
## Indicators of Compromise
N/A - Scudo is a hardened system library component and does not produce typical IoCs unless an exploit manages to subvert its structures resulting in malicious code paths.
* File Hashes: N/A (Part of the OS/LLVM build)
* File Names: N/A
* Registry Keys: N/A
* Network Indicators: N/A
* Behavioral Indicators: Detection focuses on observing memory corruption attempts against the allocator structures (e.g., attempting to write to or read from metadata areas, or predictable allocation patterns that imply heap grooming attempts are succeeding).
## Associated Threat Actors
N/A - Scudo is a defensive technology implemented by platform vendors (like Google/Android) and LLVM. Threat actors are the ones attempting to bypass or exploit vulnerabilities *in spite* of Scudo.
## Detection Methods
Detection focuses on observing unusual memory access patterns or inputs leading to allocation or deallocation failures, rather than detecting Scudo itself.
* Signature-based detection: N/A (Signature of the allocator itself is not meaningful for detection).
* Behavioral detection: Monitoring for frequent or large memory corruption attempts that trigger Scudo's internal checks or exceptions (e.g., invalid header access during free).
* YARA rules: N/A
## Mitigation Strategies
Scudo itself *is* a mitigation strategy against heap vulnerabilities.
* Prevention measures: Utilizing Scudo as the default heap allocator (as done by modern Android) provides inherent defense against common heap corruption primitives.
* Hardening recommendations: Developers should be aware that `free-reallocate-free` and UAFs (before quarantine expires) are potential weak points:
* Avoid the `free-reallocate-free` pattern if manipulating heap state is required.
* Ensure all memory accesses respect object lifetimes, even after objects enter quarantine.
* When exploiting, exploit developers must bypass header verification or prevent chunks from reaching `free()`.
## Related Tools/Techniques
* **jemalloc:** Another heap allocator discussed in adjacent research, often used in performance-sensitive environments (and previously by Android).
* **Hardened Allocators:** General category of memory allocators designed to resist exploitation (e.g., hardened malloc, PartitionAlloc).
* **Heap Grooming:** The process that Scudo's randomization actively counters.