Bug 23529 - heap-buffer-overflow in eu-readelf
Summary: heap-buffer-overflow in eu-readelf
Status: RESOLVED FIXED
Alias: None
Product: elfutils
Classification: Unclassified
Component: backends (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-15 13:14 UTC by wcventure
Modified: 2018-09-04 07:36 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
crash-seed-buffer-over-flow (827 bytes, application/x-object)
2018-08-15 13:14 UTC, wcventure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wcventure 2018-08-15 13:14:14 UTC
Created attachment 11186 [details]
crash-seed-buffer-over-flow

when executing "./eu-readelf -aAdehIlnrsSVcp -w @@", AddressSanitizer catch a heap-buffer-overflow carsh.

==29317==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000c536 at pc 0x7f5bdaf2bfb0 bp 0x7ffff669ef70 sp 0x7ffff669ef60
READ of size 1 at 0x60600000c536 thread T0
    #0 0x7f5bdaf2bfaf in __libdw_get_uleb128_unchecked /mnt/d/Project/elfutils/libdw/memory-access.h:97
    #1 0x7f5bdaf2bfaf in dwarf_getabbrevattr_data /mnt/d/Project/elfutils/libdw/dwarf_getabbrevattr.c:60
    #2 0x42f8c2 in print_debug_abbrev_section /mnt/d/Project/elfutils/src/readelf.c:5045
    #3 0x45313f in print_debug /mnt/d/Project/elfutils/src/readelf.c:11143
    #4 0x45b07b in process_elf_file /mnt/d/Project/elfutils/src/readelf.c:996
    #5 0x462344 in process_dwflmod /mnt/d/Project/elfutils/src/readelf.c:760
    #6 0x7f5bdafcc410 in dwfl_getmodules /mnt/d/Project/elfutils/libdwfl/dwfl_getmodules.c:86
    #7 0x40f013 in process_file /mnt/d/Project/elfutils/src/readelf.c:868
    #8 0x405614 in main /mnt/d/Project/elfutils/src/readelf.c:350
    #9 0x7f5bda65082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #10 0x406118 in _start (/mnt/d/Project/elfutils/build/bin/eu-readelf+0x406118)

0x60600000c536 is located 0 bytes to the right of 54-byte region [0x60600000c500,0x60600000c536)
allocated by thread T0 here:
    #0 0x7f5bdb328602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x7f5bdac62680 in convert_data /mnt/d/Project/elfutils/libelf/elf_getdata.c:164
    #2 0x7f5bdac62680 in __libelf_set_data_list_rdlock /mnt/d/Project/elfutils/libelf/elf_getdata.c:431

SUMMARY: AddressSanitizer: heap-buffer-overflow /mnt/d/Project/elfutils/libdw/memory-access.h:97 __libdw_get_uleb128_unchecked
Shadow bytes around the buggy address:
  0x0c0c7fff9850: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c7fff9860: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c0c7fff9870: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
  0x0c0c7fff9880: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c7fff9890: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
=>0x0c0c7fff98a0: 00 00 00 00 00 00[06]fa fa fa fa fa fd fd fd fd
  0x0c0c7fff98b0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c7fff98c0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c0c7fff98d0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
  0x0c0c7fff98e0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c7fff98f0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==29317==ABORTING
Comment 1 Mark Wielaard 2018-08-15 15:35:11 UTC
Replicated with valgrind:

valgrind -q eu-readelf --debug-dump=abbrev Buffer-over-readelf

==21205== Invalid read of size 1
==21205==    at 0x4855B45: __libdw_get_uleb128_unchecked (memory-access.h:97)
==21205==    by 0x4855B45: dwarf_getabbrevattr_data (dwarf_getabbrevattr.c:60)
==21205==    by 0x116573: print_debug_abbrev_section (readelf.c:5045)
==21205==    by 0x11E090: print_debug (readelf.c:11143)
==21205==    by 0x11FEA9: process_elf_file (readelf.c:996)
==21205==    by 0x11FEA9: process_dwflmod (readelf.c:760)
==21205==    by 0x486C460: dwfl_getmodules (dwfl_getmodules.c:86)
==21205==    by 0x1143BF: process_file (readelf.c:868)
==21205==    by 0x111C13: main (readelf.c:350)
==21205==  Address 0x5115416 is 0 bytes after a block of size 54 alloc'd
==21205==    at 0x48357BF: malloc (vg_replace_malloc.c:299)
==21205==    by 0x489E287: convert_data (elf_getdata.c:164)
==21205==    by 0x489E287: __libelf_set_data_list_rdlock (elf_getdata.c:431)
==21205==    by 0x489E387: __elf_getdata_rdlock (elf_getdata.c:538)
==21205==    by 0x484DF80: check_section (dwarf_begin_elf.c:167)
==21205==    by 0x484E4E2: global_read (dwarf_begin_elf.c:310)
==21205==    by 0x484E4E2: dwarf_begin_elf (dwarf_begin_elf.c:434)
==21205==    by 0x486E767: load_dw (dwfl_module_getdwarf.c:1340)
==21205==    by 0x486E98B: find_dw (dwfl_module_getdwarf.c:1390)
==21205==    by 0x486E98B: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1445)
==21205==    by 0x11DB1A: print_debug (readelf.c:10874)
==21205==    by 0x11FEA9: process_elf_file (readelf.c:996)
==21205==    by 0x11FEA9: process_dwflmod (readelf.c:760)
==21205==    by 0x486C460: dwfl_getmodules (dwfl_getmodules.c:86)
==21205==    by 0x1143BF: process_file (readelf.c:868)
==21205==    by 0x111C13: main (readelf.c:350)

The issue is that __libdw_getabbrev (used by dwarf_getabbrev, dwarf_offabbrev) uses a different "end of attributes" condition than dwarf_getabbrevattr[_data]:

  while (attrname != 0 && attrform != 0);

vs

      /* If both values are zero the index is out of range.  */
      if (name == 0 && form == 0)

Since the spec says: "The series of attribute specifications ends with an entry containing 0 for the name and 0 for the form." the second form is correct. And the check in __libdw_getabbrev should be:

while (attrname != 0 || attrform != 0);
Comment 2 Mark Wielaard 2018-08-18 20:51:36 UTC
commit 6983e59b727458a6c64d9659c85f08218bc4fcda
Author: Mark Wielaard <mark@klomp.org>
Date:   Sat Aug 18 19:51:27 2018 +0200

    libdw: Check end of attributes list consistently.
    
    dwarf_child (__libdw_find_attr), dwarf_getabbrevattr[_data] and
    dwarf_getattrs all assume the end of the attribute list is when
    both the name (code) and form of the attribute are zero.
    
    dwarf_getabbrev (__libdw_getabbrev) and dwarf_hasattr assume the
    end of the attribute list is when either the name (code) or the
    form of the attribute is zero.
    
    The DWARF spec says: "The series of attribute specifications ends
    with an entry containing 0 for the name and 0 for the form." So
    the first check is correct.
    
    Make sure dwarf_getabbrev and dwarf_hasattr use the same check.
    This is important since all other functions expect dwarf_getabbrev
    (__libdw_getabbrev) to have done a data sanity check of the attribute.
    So if the ending condition is different it could cause a crash.
    
    https://sourceware.org/bugzilla/show_bug.cgi?id=23529
    
    Signed-off-by: Mark Wielaard <mark@klomp.org>
Comment 3 Mark Wielaard 2018-09-04 07:36:52 UTC
CVE-2018-16403