Bug 32656 - eu-readelf SEGV (buffer over read) in dump_data_section (src/readelf.c:13312)
Summary: eu-readelf SEGV (buffer over read) in dump_data_section (src/readelf.c:13312)
Status: RESOLVED FIXED
Alias: None
Product: elfutils
Classification: Unclassified
Component: tools (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Mark Wielaard
URL:
Keywords:
: 32657 (view as bug list)
Depends on:
Blocks:
 
Reported: 2025-02-07 09:26 UTC by 孙文举
Modified: 2025-02-17 16:54 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2025-02-08 00:00:00
Project(s) to access:
ssh public key:


Attachments
poc (761 bytes, application/x-executable)
2025-02-07 09:26 UTC, 孙文举
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 孙文举 2025-02-07 09:26:07 UTC
Created attachment 15927 [details]
poc

**Description**
A segv can occur in eu-readelf  when using the  -z and -x options with a specially crafted input file. This issue leads to buffer-overflow

**Affected Version**
elfutils 0.192

**Steps to Reproduce**

Build elfutils 0.192 with AddressSanitizer (e.g., CFLAGS="-g -fsanitize=address" ./configure && make -j).

/mnt/data/optfuzz/benchmark/elfutils-0.192/bins/bin/eu-readelf -z -x 6 /tmp/poc
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1889020==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fc3af0914d0 bp 0x7ffda19688b0 sp 0x7ffda1968010 T0)
==1889020==The signal is caused by a READ memory access.
==1889020==Hint: address points to the zero page.
    #0 0x7fc3af0914cf in __interceptor_strncmp ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:449
    #1 0x56189b286c4d in startswith ../lib/system.h:117
    #2 0x56189b2e2e47 in dump_data_section /mnt/data/optfuzz/benchmark/elfutils-0.192/src/readelf.c:13312
    #3 0x56189b2e3ad5 in for_each_section_argument /mnt/data/optfuzz/benchmark/elfutils-0.192/src/readelf.c:13440
    #4 0x56189b2e3e7b in dump_data /mnt/data/optfuzz/benchmark/elfutils-0.192/src/readelf.c:13470
    #5 0x56189b28c062 in process_elf_file /mnt/data/optfuzz/benchmark/elfutils-0.192/src/readelf.c:1080
    #6 0x56189b28ab5b in process_dwflmod /mnt/data/optfuzz/benchmark/elfutils-0.192/src/readelf.c:840
    #7 0x7fc3afb5b708 in dwfl_getmodules /mnt/data/optfuzz/benchmark/elfutils-0.192/libdwfl/dwfl_getmodules.c:86
    #8 0x56189b28b5b9 in process_file /mnt/data/optfuzz/benchmark/elfutils-0.192/src/readelf.c:948
    #9 0x56189b2891e6 in main /mnt/data/optfuzz/benchmark/elfutils-0.192/src/readelf.c:417
    #10 0x7fc3aedd0082 in __libc_start_main ../csu/libc-start.c:308
    #11 0x56189b286b2d in _start (/mnt/data/optfuzz/benchmark/elfutils-0.192/bins/bin/eu-readelf+0x6bb2d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:449 in __interceptor_strncmp
==1889020==ABORTING

**Env**
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal
Comment 1 Mark Wielaard 2025-02-08 22:15:18 UTC
Replicated using valgrind and eu-readelf -x 6 -z

==742249== Invalid read of size 1
==742249==    at 0x484BB30: strncmp (vg_replace_strmem.c:717)
==742249==    by 0x401D2A: startswith (system.h:118)
==742249==    by 0x429F8C: dump_data_section (readelf.c:13329)
==742249==    by 0x42A68B: for_each_section_argument (readelf.c:13457)
==742249==    by 0x42A7F8: dump_data (readelf.c:13487)
==742249==    by 0x404645: process_elf_file (readelf.c:1080)
==742249==    by 0x403C06: process_dwflmod (readelf.c:840)
==742249==    by 0x48BD942: dwfl_getmodules (dwfl_getmodules.c:86)
==742249==    by 0x40403A: process_file (readelf.c:948)
==742249==    by 0x402B55: main (readelf.c:417)
==742249==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

The issue simply is that when specifying the section to dump with a number/index and it doesn't have a name the .zdebug check fails. The fix is simple:

diff --git a/src/readelf.c b/src/readelf.c
index 3991cda81df2..576b193b092d 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -13326,7 +13326,7 @@ dump_data_section (Elf_Scn *scn, const GElf_Shdr *shdr, const char *name)
                        _("Couldn't uncompress section"),
                        elf_ndxscn (scn));
            }
-         else if (startswith (name, ".zdebug"))
+         else if (name && startswith (name, ".zdebug"))
            {
              if (elf_compress_gnu (scn, 0, 0) < 0)
                printf ("WARNING: %s [%zd]\n",

Introduced when -z support was added in commit b7105b40ccd7 ("readelf: Add -z,--decompress option.")
Comment 2 Mark Wielaard 2025-02-08 22:23:29 UTC
*** Bug 32657 has been marked as a duplicate of this bug. ***
Comment 3 Mark Wielaard 2025-02-14 08:05:13 UTC
commit 73db9d2021cab9e23fd734b0a76a612d52a6f1db
Author: Mark Wielaard <mark@klomp.org>
Date:   Sun Feb 9 00:07:39 2025 +0100

    readelf: Skip trying to uncompress sections without a name
    
    When combining eu-readelf -z with -x or -p to dump the data or strings
    in an (corrupted ELF) unnamed numbered section eu-readelf could crash
    trying to check whether the section name starts with .zdebug. Fix this
    by skipping sections without a name.
    
       * src/readelf.c (dump_data_section): Don't try to gnu decompress a
       section without a name.
       (print_string_section): Likewise.
    
    https://sourceware.org/bugzilla/show_bug.cgi?id=32656
    
    Signed-off-by: Mark Wielaard <mark@klomp.org>
Comment 4 Mark Wielaard 2025-02-17 16:54:43 UTC
Note that someone created CVE-2025-1372 for this bug without following our SECURITY policy: https://sourceware.org/cgit/elfutils/tree/SECURITY

This is NOT a security issue according to our policy:

  Since most elfutils tools are run in short-lived, local, interactive,
  development context rather than remotely "in production", we generally
  treat malfunctions as ordinary bugs rather than security vulnerabilities.

We request that people who report suspected security vulnerabilities report them through the contacts in our SECURITY policy and not through non-affiliated CNAs.