Full Report
uClibC and uClibC-ng are both standalone replacements for glibc that are extremely lightweight. These are commonly used on embedded platforms. When creating threads on the platform, the thread must create a stack. This is done with a fixed size memory address and decreases from a fixed address. Because they are using mmap with the MMAP_FIXED flag, it will overwrite all existing mappings if they are asked for. By creating a large amount of threads, other mappings may be overwritten. For instance, the code for libc could be corrupted. If the mapping is RWX, this could be used to get code execution. This attack is only possible on 32-bit because of the limit of threads that can be created. Overall, good bug report for items that are not normally talked about. Normally, if you're using mmap directly, you're probably doing something wrong.
Analysis Summary
# Vulnerability: uClibC and uClibC-ng Libpthread Memory Corruption via Thread Stack Allocation
## CVE Details
- CVE ID: CVE-2022-29503
- CVSS Score: 8.1 (High)
- CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
## Affected Systems
- Products: uClibC, uClibC-ng, Anker Eufy Homebase 2
- Versions:
- uClibC: 0.9.33.2
- uClibC-ng: 1.0.40
- Anker Eufy Homebase 2: 2.1.8.8h
- Configurations: Vulnerable when using the `linuxthreads.old` implementation (uClibC) or the `linuxthreads` implementation (uClibC-ng) for libpthread, typically configured via Buildroot settings. The issue is significantly more likely on 32-bit architectures due to address space constraints.
## Vulnerability Description
This vulnerability resides in the `libpthread` functionality (`linuxthreads.old` in uClibC or `linuxthreads` in uClibC-ng) related to thread stack allocation. When a large number of threads are created via `pthread_create`, the system calls `pthread_allocate_stack`, which calculates stack addresses by decrementing from a fixed address (`THREAD_STACK_START_ADDRESS`). These allocations utilize `mmap` with the `MAP_FIXED` flag. Because `MAP_FIXED` forces the mapping to the calculated address and overwrites any existing mappings at that location, creating enough threads can lead to the corruption or overwriting of existing memory mappings, such as those belonging to dynamically loaded libraries (like libc itself). If the overwritten memory region has RWX permissions, this can lead to arbitrary code execution. This is highly feasible on 32-bit systems due to the more limited virtual address space, requiring fewer threads to trigger conflicts.
## Exploitation
- Status: PoC available (Implied by research disclosure)
- Complexity: Medium (Requires local access to trigger thread creation loops and relies on specific memory layout influenced by 32-bit limitations)
- Attack Vector: Local (The attacker must be able to create a large number of threads.)
## Impact
- Confidentiality: High (Potential for stealing information via code execution)
- Integrity: High (Code of the application/libraries can be corrupted leading to arbitrary modification)
- Availability: High (Application crash or failure due to corruption of critical components)
## Remediation
### Patches
Specific patch details are not provided in the summary, but users should update to versions released after September 22, 2022, utilizing fixed versions of uClibC/uClibC-ng that no longer use `mmap` with `MAP_FIXED` for thread stack creation, or use a configuration that avoids the specified `linuxthreads` implementations.
### Workarounds
1. **Avoid `MAP_FIXED`:** If possible, avoid using memory allocation mechanisms that directly rely on `mmap` with `MAP_FIXED` for self-managed memory segments like thread stacks, or ensure stack allocation is handled robustly without fixed addresses that conflict with loaded segments.
2. **Limit Thread Creation:** Restrict the maximum number of threads that can be spawned by an unprivileged user or process, especially on 32-bit systems, to prevent reaching the threshold where memory corruption occurs.
3. **Use Alternative libc/Threading Implementations:** Utilize glibc or other thread libraries if deploying on critical infrastructure where these vulnerabilities are present.
## Detection
- **Indicators of Compromise:** Observation of unusual memory regions (e.g., RWX segments created unexpectedly) or crashes occurring shortly after a high volume of `pthread_create` calls. Monitoring for application code modification or execution flow hijacking.
- **Detection Methods and Tools:** Memory analysis tools capable of tracking `mmap` calls with the `MAP_FIXED` flag and analyzing address space layout, especially when thread count spikes.
## References
- Vendor Advisories: TALOS-2022-1517 (Cisco Talos Intelligence Group)
- Relevant Links:
- `hXXps://talosintelligence.com/vulnerability_reports/TALOS-2022-1517`