The security landscape is always full of surprises, and CVE-2022-48064 is an interesting case. This vulnerability, found in GNU Binutils before version 2.40, revolves around the bfd_dwarf2_find_nearest_line_with_alt function in the dwarf2.c file. By exploiting this bug, an attacker can craft a malicious ELF file to trigger excessive memory consumption—potentially causing a Denial-of-Service (DoS) attack.

In this long read, we’ll walk through what happened, how the bug works, including simple code demonstration, and how attackers can exploit it. If you want the real, technical nitty-gritty, keep reading.

What Is GNU Binutils?

GNU Binutils is a collection of binary tools for working with object files, executables, libraries, and assembly code – like objdump, nm, and readelf. These tools are essential, especially in the Linux world, and are used by developers, security auditors, and anyone poking at compiled code or debugging issues.

Understanding DWARF and ELF

- ELF stands for Executable and Linkable Format, a common file format for executables, object code, shared libraries, and core dumps.

DWARF is a debugging data format used to support debugging information inside binaries.

The function at the heart of CVE-2022-48064, bfd_dwarf2_find_nearest_line_with_alt, is responsible for parsing some of this debug information.

The Vulnerability: What Went Wrong?

The core issue is excessive memory consumption (out-of-memory or OOM scenario). The vulnerable function processes DWARF data inside ELF files. If an attacker crafts a malicious file with messed-up or looping debug data, bfd_dwarf2_find_nearest_line_with_alt essentially keeps chewing through memory, not realizing it’s being led astray.

Binutils tool (like objdump or nm) opens the file.

3. While parsing the DWARF data, bfd_dwarf2_find_nearest_line_with_alt allocates more memory than it should.

Vulnerable Code Example

Let’s look at a simplified version of the kind of logic in dwarf2.c. The real code is complex, but the general pitfall is shown below:

// Simplified pseudo-code
char *line = NULL;
size_t len = ;

while (parsing_dwarf_sections) {
    // Suppose get_next_line allocates memory for us
    char *next = get_next_line(&len);
    if (!next) break;

    // Vulnerability: Not checking len, or not freeing previous line
    line = realloc(line, len);
    memcpy(line, next, len);

    // process the line...
}
free(line);

If get_next_line (really, DWARF data parsing logic) just keeps returning garbage or repeats, memory usage explodes. The bug stems from not having proper guards against bogus or recursive debug entries in a malformed ELF.

Proof-of-Concept (PoC): Crafting an ELF to Crash Binutils

While raw PoCs are sometimes withheld due to ethical issues, here’s a conceptual PoC showing how you might trigger this in a safe, educational context with a dummy ELF:

# Not a real crash, but demonstrates principle: feed big (or looping) debug data
$ printf '\x7fELF' > bad.elf
$ dd if=/dev/zero bs=1M count=100 >> bad.elf  # Pad with junk to simulate huge debug sec
# Try to read it with an older binutils:
$ objdump -W bad.elf

With a real crafted DWARF section designed to confuse bfd_dwarf2_find_nearest_line_with_alt, this would push the tool into eating all available memory.

Original researcher PoCs (for educational and responsible disclosure purposes)

- huntr.dev Report #1
- oss-fuzz finding

DNS? Or DoS Attack?

The CVE states "cause a DNS attack" which is likely a typo for DoS (Denial-of-Service). There’s no direct link to DNS resolution here; the key is that the vulnerable function can be abused to exhaust system memory, causing the program—and possibly the server or build system—to crash.

Impact: Why Does It Matter?

- Denial-of-Service: A developer or build server processing attacker-supplied ELF files could be bombed.

Attack Surface: Any automation parsing untrusted binaries with binutils tools is at risk.

- Potential for Chaining: While not directly RCE, it might be a stepping stone in a larger exploitation chain.

Fixed in GNU Binutils 2.40

- Patch example: input validation before excessive allocation, proper cycle and bounds checking in DWARF parsing.

Upgrade your binutils! If you’re packaging, CI-ing, or analyzing untrusted ELF files, check your versions.

References

- NVD Entry for CVE-2022-48064
- huntr.dev vulnerability report
- OSS-Fuzz report
- GNU Binutils Official

Summary

CVE-2022-48064 is a clear reminder that even simple things like parsing debug info can lead to serious vulnerabilities if not carefully handled. Patching your tools is essential, and always sanitize and limit what untrusted files your automation touches. Stay safe, and happy hacking!


If you want more deep dives like this, let us know!

Timeline

Published on: 08/22/2023 19:16:30 UTC
Last modified on: 11/07/2023 03:56:28 UTC