[Bug libelf/28666] New: memmove() reads out-of-range in elf32_xlatetom

[Bug libelf/28666] New: memmove() reads out-of-range in elf32_xlatetom

[netfirewall at gmail dot com]

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

            Bug ID: 28666
           Summary: memmove() reads out-of-range in elf32_xlatetom
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libelf
          Assignee: unassigned at sourceware dot org
          Reporter: netfirewall at gmail dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Created attachment 13829
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13829&action=edit
poc1

Hi,

A memmove() reads out-of-range was triggered when we were fuzzing the elfutils.
The same issue can be triggered in the release version 0.186 and the upstream
version.

We fuzzed with a modified oss-fuzz, so it can be reproduced with oss-fuzz
steup. Here are the steps to reproduce (poc1 is attached):

> 1. git clone https://github.com/google/oss-fuzz.git
> 2. cd oss-fuzz
> 3. python3 infra/helper.py build_fuzzers --engine libfuzzer --sanitizer address elfutils
> 4. python3 infra/helper.py reproduce elfutils fuzz-dwfl-core ./poc1

The same payload also crashes the release 0.186 (commit
983e86fd89e8bf02f2d27ba5dce5bf078af4ceda). To reproduce on 0.186, edit
oss-fuzz/projects/elfutils/Dockerfile as below, and follow the same steps
above.

> FROM gcr.io/oss-fuzz-base/base-builder
> RUN apt-get update && \
>     apt-get install -y pkg-config make autoconf autopoint zlib1g-dev flex bison gawk
> RUN git clone git://sourceware.org/git/elfutils.git
> WORKDIR elfutils
> RUN git checkout 983e86fd89e8bf02f2d27ba5dce5bf078af4ceda
> COPY build.sh *.c *.zip $SRC/

Here is the ASAN dump (upstream, commit
66f704ae705a489d35cd03aa9687e192a844d766):

> ==13==ERROR: AddressSanitizer: unknown-crash on address 0x7fab2f62e000 at pc 0x00000052487f bp 0x7ffe9c2ec120 sp 0x7ffe9c2eb8e8[35/1970]
> READ of size 1790976 at 0x7fab2f62e000 thread T0                                                                                        
> SCARINESS: 16 (multi-byte-read-unknown-crash)                                                                                           
>     #0 0x52487e in __asan_memmove /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3                       
>     #1 0x63ca73 in memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:40:10                                                  
>     #2 0x63ca73 in elf32_xlatetom /src/elfutils/libelf/elf32_xlatetom.c:96:2                                                            
>     #3 0x5fc040 in dwfl_link_map_report /src/elfutils/libdwfl/link_map.c:895:12                                                         
>     #4 0x56631a in dwfl_core_file_report /src/elfutils/libdwfl/core-file.c:548:16                                                       
>     #5 0x55e4e0 in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6                                                                    
>     #6 0x456cb3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp                             
>     #7 0x4425b2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver
> .cpp:324:6                                                                                                                              
>     #8 0x44807a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp                
>     #9 0x470f62 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10                                                   
>     #10 0x7fab304800b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)                                                   
>     #11 0x41f83d in _start (/out/fuzz-dwfl-core+0x41f83d)                                                                               
>                                                                                                                                         
> DEDUP_TOKEN: __asan_memmove--memmove--elf32_xlatetom                                                                                    
> Address 0x7fab2f62e000 is a wild pointer inside of access range of size 0x0000001b5400.                                                 
> SUMMARY: AddressSanitizer: unknown-crash /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3 in __asan_memmo
> ve                                                                                                                                      
> Shadow bytes around the buggy address:                                                                                                  
>   0x0ff5e5ebdbb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                       
>   0x0ff5e5ebdbc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                       
>   0x0ff5e5ebdbd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                       
>   0x0ff5e5ebdbe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                       
>   0x0ff5e5ebdbf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                       
> =>0x0ff5e5ebdc00:[fe]fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe                                                                       
>   0x0ff5e5ebdc10: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe                                                                       
>   0x0ff5e5ebdc20: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>   0x0ff5e5ebdc30: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>   0x0ff5e5ebdc40: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>   0x0ff5e5ebdc50: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
> 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

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[evvers at ya dot ru]

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

Evgeny Vereshchagin <evvers at ya dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |evvers at ya dot ru

--- Comment #1 from Evgeny Vereshchagin <evvers at ya dot ru> ---
FWIW There are a lot of moving parts there so in
https://github.com/google/oss-fuzz/pull/6944 I tried to make it easier to
reproduce bugs found by the fuzz target without Docker used by the oss-fuzz
toolchain. To that end I added a comment where I tried to explain how to build
it manually with clang and the build dependencies of elfutils:
https://github.com/google/oss-fuzz/blob/5f83a8b6811eaa6b1a0aa574e095ed0def8a0ce3/projects/elfutils/build.sh#L18-L36.

Apart from that I'm pretty sure all the bugs that can be found by the fuzz
target (in its current form at least) can be triggered with `./src/stack --core
...` built with ASan/UBsan or under Valgrind so this particular issue can be
triggered by running something like
```
autoreconf -i -f
./configure --enable-maintainer-mode CFLAGS='-g -O1 -fno-omit-frame-pointer
-fsanitize=address' CXXFLAGS='-g -O1 -fno-omit-frame-pointer
-fsanitize=address'
ASAN_OPTIONS=detect_leaks=0 make -j$(nproc) V=1
$ LD_PRELOAD="/lib64/libasan.so.6 ./libelf/libelf.so ./libdw/libdw.so" 
./src/stack --core ../poc1
AddressSanitizer:DEADLYSIGNAL
=================================================================
==52660==ERROR: AddressSanitizer: SEGV on unknown address 0x7fd5b4e5d000 (pc
0x7fd5b8a86368 bp 0x7fff4773cb50 sp 0x7fff4773cb18 T0)
==52660==The signal is caused by a READ memory access.
    #0 0x7fd5b8a86368 in __sanitizer::internal_memmove(void*, void const*,
unsigned long) (/lib64/libasan.so.6+0xc5368)
    #1 0x7fd5b898aa42 in memmove /usr/include/bits/string_fortified.h:36
    #2 0x7fd5b898aa42 in elf32_xlatetom
/home/vagrant/elfutils/libelf/elf32_xlatetom.c:96
    #3 0x7fd5b88c285b in dwfl_link_map_report
/home/vagrant/elfutils/libdwfl/link_map.c:895
    #4 0x7fd5b88c7877 in _new.dwfl_core_file_report
/home/vagrant/elfutils/libdwfl/core-file.c:548
    #5 0x4037b8 in parse_opt /home/vagrant/elfutils/src/stack.c:595
    #6 0x7fd5b84bef81 in __argp_parse (/lib64/libc.so.6+0x10cf81)
    #7 0x404b7d in main /home/vagrant/elfutils/src/stack.c:695
    #8 0x7fd5b83d9b74 in __libc_start_main (/lib64/libc.so.6+0x27b74)
    #9 0x40256d in _start (/home/vagrant/elfutils/src/stack+0x40256d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.6+0xc5368) in
__sanitizer::internal_memmove(void*, void const*, unsigned long)
==52660==ABORTING
```

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at sourceware dot org   |mark at klomp dot org
                 CC|                            |mark at klomp dot org
   Last reconfirmed|                            |2021-12-07

--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
It does indeed replicate under valgrind using eu-stack with any build:

$ valgrind eu-stack --core poc1 
==444== Memcheck, a memory error detector
==444== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==444== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==444== Command: eu-stack --core poc1
==444== 
==444== Invalid read of size 8
==444==    at 0x4C2E68C: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1034)
==444==    by 0x4E3C2FB: UnknownInlinedFun (string3.h:57)
==444==    by 0x4E3C2FB: elf32_xlatetom (elf32_xlatetom.c:100)
==444==    by 0x5086081: dwfl_link_map_report (link_map.c:894)
==444==    by 0x5087D7A: dwfl_core_file_report@@ELFUTILS_0.158
(core-file.c:532)
==444==    by 0x402736: parse_opt (stack.c:590)
==444==    by 0x58B7E83: group_parse (argp-parse.c:256)
==444==    by 0x58B7E83: parser_finalize (argp-parse.c:603)
==444==    by 0x58B7E83: argp_parse (argp-parse.c:921)
==444==    by 0x401CE5: main (stack.c:690)
==444==  Address 0x4025000 is not stack'd, malloc'd or (recently) free'd

I see what is going on. In link_map we try to read in the phdrs, but we can
only read a small amount (the ph_num field is crazy big). So we set the
in.d_size to just the size we can read in. But then for the conversion we set
out.d_size based on the crazy big ph_num. Then we try to convert not just the
phdrs that we could read, but a much bigger amount. And crash...

This is an odd failure, it only happens when trying to read a big endian core
file on an little endian architecture (or the other way around), and that core
file is also clearly corrupted.

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[mark at klomp dot org]

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

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
Proposed patch:
https://patchwork.sourceware.org/project/elfutils/patch/20211208133606.7658-1-mark@klomp.org/

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[evvers at ya dot ru]

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

--- Comment #4 from Evgeny Vereshchagin <evvers at ya dot ru> ---
With that patch applied I can confirm that the issue is gone.Just to make sure
also run the unit tests on aarch64, i386, ppc64le and x86_64 and they all
passed there. Thanks!

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[evvers at ya dot ru]

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

--- Comment #5 from Evgeny Vereshchagin <evvers at ya dot ru> ---
I was able to trigger the same issue with a different file by running the fuzz
target a bit longer. I'll double check and attach the file

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[evvers at ya dot ru]

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

--- Comment #6 from Evgeny Vereshchagin <evvers at ya dot ru> ---
My bad. The backtrace is different there:
```
2021-12-08T20:14:08.7167911Z ==21==ERROR: AddressSanitizer:
heap-buffer-overflow on address 0x7f4f1d328000 at pc 0x000000524c9f bp
0x7fff9271bc40 sp 0x7fff9271b408
2021-12-08T20:14:08.7169143Z READ of size 327680 at 0x7f4f1d328000 thread T0
2021-12-08T20:14:08.7170393Z SCARINESS: 26
(multi-byte-read-heap-buffer-overflow)
2021-12-08T20:14:08.7429032Z     #0 0x524c9e in __asan_memmove
/src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3
2021-12-08T20:14:08.7434627Z     #1 0x63d0b3 in memmove
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:40:10
2021-12-08T20:14:08.7438180Z     #2 0x63d0b3 in elf32_xlatetom
/src/elfutils/libelf/elf32_xlatetom.c:96:2
2021-12-08T20:14:08.7441601Z     #3 0x5fc7e8 in dwfl_link_map_report
/src/elfutils/libdwfl/link_map.c:1013:12
2021-12-08T20:14:08.7445515Z     #4 0x5668da in dwfl_core_file_report
/src/elfutils/libdwfl/core-file.c:548:16
2021-12-08T20:14:08.7448767Z     #5 0x55eaa0 in LLVMFuzzerTestOneInput
/src/fuzz-dwfl-core.c:52:6
```

I think the issue reported here is gone. Thanks!

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #7 from Mark Wielaard <mark at klomp dot org> ---
Could you open a new bug report for the issue in comment #6?

It is indeed a different issue, although very similar to this one.
I can probably create a fix just from that backtrace, but having a reproducer
would be great.

Thanks for testing, pushed as:

commit 809f2d70ec770d512cf6b1e70a67f5eb84c4508c
Author: Mark Wielaard <mark@klomp.org>
Date:   Wed Dec 8 13:39:47 2021 +0100

    libdwfl: Don't try to convert too many bytes in dwfl_link_map_report

    When trying to read (corrupt) phdrs from a core file we only want
    to read and convert the bytes we could read. Also make sure we don't
    try to allocate too big buffers.

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

    Signed-off-by: Mark Wielaard <mark@klomp.org>

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[evvers at ya dot ru]

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

--- Comment #8 from Evgeny Vereshchagin <evvers at ya dot ru> ---
Created attachment 13840
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13840&action=edit
File triggering an "invalid read"

I've just added a file triggering that issue.

```
$ git describe
elfutils-0.186-20-g98e7adf7

autoreconf -i -f
./configure --enable-maintainer-mode
make -j$(nproc) V=1
$ DEBUGINFOD_URLS= LD_PRELOAD="./libelf/libelf.so ./libdw/libdw.so" valgrind
--leak-check=full ./src/stack --core
../crash-51ef1bcb1fbd741ff5fde645079625a8ed871225
==55019== Memcheck, a memory error detector
==55019== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==55019== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==55019== Command: ./src/stack --core
../crash-51ef1bcb1fbd741ff5fde645079625a8ed871225
==55019==
==55019== Invalid read of size 8
==55019==    at 0x484B214: memmove (vg_replace_strmem.c:1382)
==55019==    by 0x48585DF: memmove (string_fortified.h:36)
==55019==    by 0x48585DF: elf32_xlatetom (elf32_xlatetom.c:96)
==55019==    by 0x48C793A: dwfl_link_map_report (link_map.c:1013)
==55019==    by 0x48C8CA5: dwfl_core_file_report@@ELFUTILS_0.158
(core-file.c:548)
==55019==    by 0x402EC6: parse_opt (stack.c:595)
==55019==    by 0x4C4D591: argp_parse (in /usr/lib64/libc.so.6)
==55019==    by 0x4024EA: main (stack.c:695)
==55019==  Address 0x6026000 is not stack'd, malloc'd or (recently) free'd
==55019==
```

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

[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom

[mark at klomp dot org]

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

--- Comment #9 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Evgeny Vereshchagin from comment #8)
> Created attachment 13840 [details]
> File triggering an "invalid read"
> 
> I've just added a file triggering that issue.

Thanks, I opened a new bug report for this:
https://sourceware.org/bugzilla/show_bug.cgi?id=28677

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