[Bug libelf/27076] New: heap-buffer-overflow when calling file_read_elf function in elf_begin.c in libelf

[Bug libelf/27076] New: heap-buffer-overflow when calling file_read_elf function in elf_begin.c in libelf

[2060271023 at email dot szu.edu.cn]

https://sourceware.org/bugzilla/show_bug.cgi?id=27076

            Bug ID: 27076
           Summary: heap-buffer-overflow when calling file_read_elf
                    function in elf_begin.c in libelf
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libelf
          Assignee: unassigned at sourceware dot org
          Reporter: 2060271023 at email dot szu.edu.cn
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Created attachment 13055
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13055&action=edit
the crafted input causing heap-buffer-overflow

Hi, 

A Heap-buffer-overflow problem was discovered in the function file_read_elf in
elf_begin.c in libelf, as distributed in elfutils-0.182. A crafted input can
cause segment faults and I have confirmed them with address sanitizer too.

Here are the POC files. Please use "./eu-stack --core=$POS -abdilmsv" to
reproduce the error.

$ git log

> commit 609290a61d4f900c65b7e0e273981022a826e4c0 (HEAD -> master, origin/master, origin/HEAD)
> Author: Mark Wielaard <mark@klomp.org>
> Date:   Sun Nov 29 01:57:53 2020 +0100
> 
>     libdwfl: Use 64bit GElf_Addr instead of size_t to calculate address.
> 
>     size_t is too small on 32 bit systems to analyze a 64 bit core file.
> 
>     Signed-off-by: Mark Wielaard <mark@klomp.org>

The ASAN dumps the stack trace as follows:

> =================================================================
> ==5661==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000000b0 at pc 0x7f3dda845483 bp 0x7ffcfffb4ad0 sp 0x7ffcfffb4ac0
> READ of size 2 at 0x6060000000b0 thread T0
>     #0 0x7f3dda845482 in file_read_elf /elfutils/libelf/elf_begin.c:453
>     #1 0x7f3dda845482 in __libelf_read_mmaped_file /elfutils/libelf/elf_begin.c:552
>     #2 0x7f3dda54f44f in dwfl_segment_report_module /elfutils/libdwfl/dwfl_segment_report_module.c:955
>     #3 0x7f3dda567165 in dwfl_core_file_report /elfutils/libdwfl/core-file.c:558
>     #4 0x5584957f0f15 in parse_opt /elfutils/src/stack.c:595
>     #5 0x7f3dd9fe0d4a in argp_parse (/lib/x86_64-linux-gnu/libc.so.6+0x12fd4a)
>     #6 0x5584957f01f4 in main /elfutils/src/stack.c:695
>     #7 0x7f3dd9ed2bf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
>     #8 0x5584957f0bc9 in _start (/elfutils/build/bin/eu-stack+0x5bc9)
> 
> 0x6060000000b1 is located 0 bytes to the right of 49-byte region [0x606000000080,0x6060000000b1)
> allocated by thread T0 here:
>     #0 0x7f3ddabc9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
>     #1 0x7f3dda54f1a6 in dwfl_segment_report_module /elfutils/libdwfl/dwfl_segment_report_module.c:907
>     #2 0x7f3dda567165 in dwfl_core_file_report /elfutils/libdwfl/core-file.c:558
>     #3 0x5584957f0f15 in parse_opt /elfutils/src/stack.c:595
>     #4 0x7f3dd9fe0d4a in argp_parse (/lib/x86_64-linux-gnu/libc.so.6+0x12fd4a)
>     #5 0x5584957f01f4 in main /elfutils/src/stack.c:695
>     #6 0x7f3dd9ed2bf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
> 
> SUMMARY: AddressSanitizer: heap-buffer-overflow /elfutils/libelf/elf_begin.c:453 in file_read_elf
> Shadow bytes around the buggy address:
>   0x0c0c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c0c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c0c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c0c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c0c7fff8000: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
> =>0x0c0c7fff8010: 00 00 00 00 00 00[01]fa fa fa fa fa fa fa fa fa
>   0x0c0c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c0c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c0c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c0c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c0c7fff8060: fa fa fa fa fa fa fa fa fa fa fa 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
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   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
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
> ==5661==ABORTING

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libelf/27076] heap-buffer-overflow when calling file_read_elf function in elf_begin.c in libelf

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27076

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mark at klomp dot org
         Resolution|---                         |FIXED

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
I couldn't reproduce a crash, but there is a small (1 byte) over-read detected
by valgrind:

==12591== Memcheck, a memory error detector
==12591== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12591== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==12591== Command: src/stack --core ./POC -abdilmsv
==12591== 
==12591== Invalid read of size 2
==12591==    at 0x4E3A768: get_shnum (elf_begin.c:139)
==12591==    by 0x4E3A768: file_read_elf (elf_begin.c:289)
==12591==    by 0x4E3AE48: __libelf_read_mmaped_file (elf_begin.c:552)
==12591==    by 0x50A969A: dwfl_segment_report_module
(dwfl_segment_report_module.c:955)
==12591==    by 0x50AC773: dwfl_core_file_report@@ELFUTILS_0.158
(core-file.c:558)
==12591==    by 0x4025B6: parse_opt (stack.c:595)
==12591==    by 0x56FACE3: argp_parse (in /usr/lib64/libc-2.17.so)
==12591==    by 0x401C12: main (stack.c:695)
==12591==  Address 0x6c182a0 is 48 bytes inside a block of size 49 alloc'd
==12591==    at 0x4C2C089: calloc (vg_replace_malloc.c:762)
==12591==    by 0x50A961E: dwfl_segment_report_module
(dwfl_segment_report_module.c:907)
==12591==    by 0x50AC773: dwfl_core_file_report@@ELFUTILS_0.158
(core-file.c:558)
==12591==    by 0x4025B6: parse_opt (stack.c:595)
==12591==    by 0x56FACE3: argp_parse (in /usr/lib64/libc-2.17.so)
==12591==    by 0x401C12: main (stack.c:695)
==12591== 
src/stack: dwfl_core_file_attach: (null)
==12591== 
==12591== HEAP SUMMARY:
==12591==     in use at exit: 2,536 bytes in 11 blocks
==12591==   total heap usage: 43 allocs, 32 frees, 14,913 bytes allocated
==12591== 
==12591== LEAK SUMMARY:
==12591==    definitely lost: 0 bytes in 0 blocks
==12591==    indirectly lost: 0 bytes in 0 blocks
==12591==      possibly lost: 0 bytes in 0 blocks
==12591==    still reachable: 2,536 bytes in 11 blocks
==12591==         suppressed: 0 bytes in 0 blocks
==12591== Rerun with --leak-check=full to see details of leaked memory
==12591== 
==12591== For lists of detected and suppressed errors, rerun with: -s
==12591== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Fixed by making sure we have at least a full Ehdr available (which is 52 or 64
bytes in size):
https://sourceware.org/pipermail/elfutils-devel/2020q4/003322.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.