Hello GNU Binutils maintainers, I would like to responsibly report a security-relevant objdump issue affecting the DLX ELF backend.
Important note: The attached README notes that a similar/related finding appears to have already been reported publicly at: https://github.com/4D4J/objdump-Out-Of-Bounds-write Please treat this submission as a supplemental reproduction package and validation report unless you determine that it is a distinct issue or materially different exploit path. I am not trying to claim priority over the earlier public work. Summary: A crafted ELF/DLX object can trigger an out-of-bounds write while `objdump -g` processes DLX relocation/debug information. In the provided local proof environment, the crash can be shaped into an ACE-style local parser exploit that reaches a helper command named `P`, which records `CALC_HELPER_RAN` and launches Calculator. This is not a network RCE by itself. The attacker-controlled input is a crafted object file, and the victim action is running objdump on it, directly or through tooling/CI that invokes objdump on untrusted objects. Tested targets: - binutils-gdb master commit: c311f4d37f31ff3fbb5db6923abcdf93bb75a37b - GNU Binutils release: 2.46.1 - Target backend: `elf32-dlx` - Trigger: `objdump -g <crafted-ELF-DLX-object>` Impact: If a user, CI pipeline, malware-analysis workflow, reverse-engineering workflow, build system, or automated triage service runs a vulnerable `objdump -g` on an untrusted crafted DLX ELF object, memory corruption may be reachable. The attached PoC demonstrates a local crash-to-helper execution path in a matching profile. The ASLR bypass is ASLR-on but profile-dependent. It is not claimed to be a deterministic universal single-file ASLR bypass for every unmodified objdump process. Attached files: - README.md - run_dlx_calc_poc.sh - dlx_chain_builder.py - generate_objdump_dlx_calc_poc.py - aslr-bypass-analysis.md - aslr_delta_coverage.py - search_pointer_transform.py - P Basic reproduction: ```bash cd /path/to/objdump-dlx-calc-poc chmod +x P export PATH="$PWD:$PATH" MAX_TRIES=50 bash run_dlx_calc_poc.sh /path/to/objdump cat calc_hit.log ``` Expected successful signal: ```text HIT try=1 payload=payloads/dlx_calc_aslr_gnu2461_f06_b702fff00_s7042e500.bin CALC_HELPER_RAN ... ``` Suggested fix direction: - Audit DLX relocation processing used by `objdump -g`. - Validate relocation offsets against the target debug section bounds before applying relocations. - Fail closed when relocation entries target outside the intended section or reference impossible/unsafe ranges. - Add regression tests using minimized crafted DLX ELF objects. - Consider hardening libbfd debug/relocation processing paths that can mutate debug-section state based on malformed object input. Please let me know whether this should be filed in Sourceware Bugzilla, kept private for coordinated handling, or linked to the earlier public report. # poc and more infomation in https://github.com/wtt208/GNU-Binutils-objdump.git Best regards, wtt
# GNU Binutils objdump DLX Backend Out-of-Bounds Write / Local Parser ACE-Style PoC ## 1. Executive Summary A crafted ELF/DLX object can trigger a security-relevant crash-to-code-execution path in GNU Binutils `objdump -g` through the DLX ELF backend. The issue is best described as a local parser vulnerability: the attacker supplies a crafted ELF/DLX object file, and the victim runs `objdump -g` on it. The provided proof package demonstrates that, in matching heap/libc profiles, the crash can be shaped to reach a helper command named `P`. The helper writes `calc_hit.log` and opens Calculator. This is not a network RCE by itself. The impact is relevant to users, CI systems, malware-analysis pipelines, reverse-engineering environments, and automated tooling that run objdump on untrusted object files. Important priority note: the attached README states that a similar/related public finding already exists at `https://github.com/4D4J/objdump-Out-Of-Bounds-write`. This package should be treated as supplemental validation unless maintainers determine that it is distinct. ## 2. Affected Product - Product: GNU Binutils / binutils-gdb - Tool: `objdump` - Backend: DLX ELF / `elf32-dlx` - Trigger option: `objdump -g` - Tested master commit: `c311f4d37f31ff3fbb5db6923abcdf93bb75a37b` - Tested release: GNU Binutils `2.46.1` - Format: crafted ELF/DLX object file ## 3. Vulnerability Class Suggested classification: - CWE-787: Out-of-bounds Write - CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer - CWE-20: Improper Input Validation The high-level root cause is that crafted DLX relocation/debug data can cause the DLX backend to write outside the intended debug section while processing relocations. The PoC shapes those writes so that, when the process layout matches one of the generated profiles, control flow reaches the helper command `P`. ## 4. Impact Successful exploitation may allow code execution in the context of the user or service account running objdump. Potentially affected scenarios include: - developers running objdump manually on untrusted object files, - package analysis pipelines, - CI/CD jobs that inspect user-supplied artifacts, - malware-analysis sandboxes, - reverse-engineering workflows, - automated crash triage systems, - and security scanners that invoke binutils on uploaded binaries. The exploit is local-input-driven and profile-dependent. A normal segfault alone is not the success signal. The useful success signal is Calculator opening or `calc_hit.log` receiving a fresh `CALC_HELPER_RAN ...` line. ## 5. Reproduction Package The package contains: - `README.md` — overview, tested versions, reproduction instructions, and ASLR notes. - `P` — helper script that writes `calc_hit.log` and starts Windows Calculator from WSL. - `run_dlx_calc_poc.sh` — tries generated payload variants until one hits. - `generate_objdump_dlx_calc_poc.py` — regenerates payload variants. - `dlx_chain_builder.py` — ELF/DLX payload builder used by the generator. - `aslr-bypass-analysis.md` — explanation of the ASLR-on, profile-dependent strategy. - `aslr_delta_coverage.py` — computes libc low-32 delta coverage for the generator. - `search_pointer_transform.py` — Z3 sanity check for fixed pointer-transform reasoning. Payloads are named `.bin`, but the file format inside is ELF/DLX. ## 6. Basic Reproduction From WSL or a similar local test environment: ```bash cd /path/to/objdump-dlx-calc-poc chmod +x P export PATH="$PWD:$PATH" MAX_TRIES=50 bash run_dlx_calc_poc.sh /path/to/objdump cat calc_hit.log ``` Example using a local binutils build: ```bash MAX_TRIES=50 bash run_dlx_calc_poc.sh /opt/binutils-master/binutils/objdump ``` The runner regenerates `payloads/` automatically if the folder is missing or empty. Expected successful output: ```text HIT try=1 payload=payloads/dlx_calc_aslr_gnu2461_f06_b702fff00_s7042e500.bin CALC_HELPER_RAN 2026-06-25T11:19:07Z ``` A ten-run one-sweep stability pass against a clean GNU Binutils 2.46.1 `dlx-elf` objdump build reportedly hit every run: ```text hits=10/10 CALC_HELPER_RAN 2026-06-25T11:19:31Z ``` A plain crash such as the following can occur without a successful helper execution: ```text Segmentation fault (core dumped) ``` ## 7. Manual Reproduction To run manually with ASLR enabled: ```bash cd /path/to/objdump-dlx-calc-poc chmod +x P export PATH="$PWD:$PATH" rm -f calc_hit.log for p in payloads/*.bin; do echo "$p" /path/to/objdump -g "$p" >/dev/null 2>&1 || true if [ -s calc_hit.log ]; then echo "HIT $p" cat calc_hit.log break fi done ``` One-liner: ```bash rm -f calc_hit.log; for p in payloads/*.bin; do echo "$p"; /path/to/objdump -g "$p" >/dev/null 2>&1 || true; if [ -s calc_hit.log ]; then echo "HIT $p"; cat calc_hit.log; break; fi; done ``` ## 8. Payload Regeneration ```bash rm -rf payloads python3 generate_objdump_dlx_calc_poc.py --out-dir payloads ``` The generator emits payload profiles for the measured layouts, including: - original measured profile, - WSL/Ubuntu 24.04 profile, - clean GNU Binutils 2.46.1 `dlx-elf` build profile. ## 9. ASLR Notes The PoC keeps ASLR enabled. It uses an ASLR-on relative-delta strategy, but it is not a universal single-shot info-leak bypass. The generator emits multiple payload variants for observed local profiles. The current documented profiles include: ```text layout=wsl2404 off_io=-0x3690 off_sec=0xbb0 rbase=0x220 buf_delta=0x702fff00 or 0x6f300000 system_delta=0x7042e500, 0x6f42e600, 0x7043e4ff, 0x6f43e5ff, 0x7043e5ff, or 0x6f43e6ff layout=gnu2461 off_io=-0x3690 off_sec=0xbb8 rbase=0x190 sec_size_offset=0x40 buf_delta=0x702fff00 or 0x6f300000 system_delta=0x7042e500, 0x6f42e600, 0x7043e4ff, 0x6f43e5ff, 0x7043e5ff, or 0x6f43e6ff ``` The six `system_delta` values cover every page-aligned low-32-bit libc base for the documented `_IO_2_1_stderr_` and `system` offsets. This improves libc low-32 coverage, but it does not make the heap/libio profile universal. The ASLR analysis also notes that a deterministic leak-then-exploit route did not hold for the tested trigger because the relevant relocation side effect ran for the first object only, and FIFO staging is blocked because `display_file()` calls `get_file_size()`, which rejects non-regular files before `bfd_openr()`. ## 10. Fix / Hardening Recommendations Recommended areas to review: 1. DLX relocation processing used by `objdump -g`. 2. Bounds checks for relocation offsets against the destination debug section. 3. Integer overflow or sign-extension behavior around DLX relocation offsets. 4. Range checks before mutating `.debug_info` or related debug sections. 5. Handling of malformed relocation tables and section sizes. 6. libbfd debug processing assumptions when object metadata is malformed. Suggested fixes: - Validate relocation offsets and relocation sizes before applying each relocation. - Reject relocations that target outside the intended section. - Fail closed when relocation data references impossible, negative, or wrapped offsets. - Add regression tests using minimized crafted ELF/DLX objects. - Consider fuzzing `objdump -g` across less-common BFD backends. - Consider memory-safety hardening for debug/relocation processing paths. ## 11. Suggested CVSS Suggested CVSS v3.1: ```text CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H ``` Suggested severity: High. Rationale: - Attack vector is local file parsing, not network service exposure. - The attacker does not need privileges to craft the input. - The victim must run objdump on the crafted file, or an automated process must do so. - Exploit reliability is profile-dependent, so attack complexity is high. - Successful exploitation can compromise confidentiality, integrity, and availability of the objdump process context. ## 12. Responsible Disclosure Note Because related public work may already exist, this submission should be coordinated carefully with maintainers and original researchers. Credit should not be claimed over the earlier public finding unless maintainers confirm this package describes a distinct vulnerability or materially different path.
