* [Bug libdw/24140] New: A Heap-buffer-overflow problem was discovered in the function __libdw_next_unit in dwarf_nextcu.c in libdw
@ 2019-01-26 8:16 wcventure at 126 dot com
2019-02-01 13:10 ` [Bug libdw/24140] " mark at klomp dot org
0 siblings, 1 reply; 2+ messages in thread
From: wcventure at 126 dot com @ 2019-01-26 8:16 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=24140
Bug ID: 24140
Summary: A Heap-buffer-overflow problem was discovered in the
function __libdw_next_unit in dwarf_nextcu.c in libdw
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: libdw
Assignee: unassigned at sourceware dot org
Reporter: wcventure at 126 dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Created attachment 11574
--> https://sourceware.org/bugzilla/attachment.cgi?id=11574&action=edit
POC
Hi,
A Heap-buffer-overflow problem was discovered in the function __libdw_next_unit
in dwarf_nextcu.c in libdw, as distributed in Elfutils 0.175. A crafted ELF
input can cause segment faults and I have confirmed them with address sanitizer
too.
Here are the POC files. Please use "./eu-nm -C $POC" to reproduce the error.
$git log
> commit a17c2c0917901ffa542ac4d3e327d46742219e04
> Author: Mark Wielaard <mark@klomp.org>
> Date: Tue Jan 22 15:55:18 2019 +0100
>
> readelf: Don't go past end of line data reading unknown opcode parameters.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=24116
>
> Signed-off-by: Mark Wielaard <mark@klomp.org>
The ASAN dumps the stack trace as follows:
> =================================================================
> ==12766==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000032 at pc 0x7f1605a83c52 bp 0x7ffeba226910 sp 0x7ffeba226900
> READ of size 2 at 0x603000000032 thread T0
> #0 0x7f1605a83c51 in __libdw_next_unit /home/wencheng/Experiment/elfutils/libdw/dwarf_nextcu.c:249
> #1 0x7f1605a83f3c in dwarf_next_unit /home/wencheng/Experiment/elfutils/libdw/dwarf_nextcu.c:46
> #2 0x7f1605a83f3c in dwarf_nextcu /home/wencheng/Experiment/elfutils/libdw/dwarf_nextcu.c:294
> #3 0x408273 in get_local_names /home/wencheng/Experiment/elfutils/src/nm.c:627
> #4 0x408273 in show_symbols /home/wencheng/Experiment/elfutils/src/nm.c:1285
> #5 0x40e5bd in handle_elf /home/wencheng/Experiment/elfutils/src/nm.c:1578
> #6 0x40387c in process_file /home/wencheng/Experiment/elfutils/src/nm.c:374
> #7 0x40387c in main /home/wencheng/Experiment/elfutils/src/nm.c:249
> #8 0x7f1604e6782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> #9 0x404568 in _start (/home/wencheng/Experiment/elfutils/build/bin/eu-nm+0x404568)
>
> 0x603000000032 is located 2 bytes to the right of 32-byte region [0x603000000010,0x603000000030)
> allocated by thread T0 here:
> #0 0x7f1605f4ab90 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb90)
> #1 0x7f16057feec3 in convert_data /home/wencheng/Experiment/elfutils/libelf/elf_getdata.c:157
> #2 0x7f16057feec3 in __libelf_set_data_list_rdlock /home/wencheng/Experiment/elfutils/libelf/elf_getdata.c:447
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wencheng/Experiment/elfutils/libdw/dwarf_nextcu.c:249 in __libdw_next_unit
> Shadow bytes around the buggy address:
> 0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c067fff8000: fa fa 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa
> 0x0c067fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c067fff8050: 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
> ==12766==ABORTING
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug libdw/24140] A Heap-buffer-overflow problem was discovered in the function __libdw_next_unit in dwarf_nextcu.c in libdw
2019-01-26 8:16 [Bug libdw/24140] New: A Heap-buffer-overflow problem was discovered in the function __libdw_next_unit in dwarf_nextcu.c in libdw wcventure at 126 dot com
@ 2019-02-01 13:10 ` mark at klomp dot org
0 siblings, 0 replies; 2+ messages in thread
From: mark at klomp dot org @ 2019-02-01 13:10 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=24140
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> ---
Replicated under valgrind:
$ valgrind -q eu-nm -C ./POC.unit
src/nm: ./POC.unit: entry size in section 2 `.debug_info' is not what we expect
==15242== Invalid read of size 8
==15242== at 0x4850940: __libdw_next_unit (dwarf_nextcu.c:168)
==15242== by 0x4850C24: dwarf_next_unit (dwarf_nextcu.c:46)
==15242== by 0x4850C24: dwarf_nextcu (dwarf_nextcu.c:294)
==15242== by 0x10E73B: get_local_names (nm.c:627)
==15242== by 0x10E73B: show_symbols (nm.c:1285)
==15242== by 0x10FCEA: handle_elf (nm.c:1578)
==15242== by 0x110482: process_file (nm.c:374)
==15242== by 0x10D70D: main (nm.c:249)
==15242== Address 0x525481a is 26 bytes inside a block of size 32 alloc'd
==15242== at 0x483577F: malloc (vg_replace_malloc.c:299)
==15242== by 0x48A0358: convert_data (elf_getdata.c:157)
==15242== by 0x48A0358: __libelf_set_data_list_rdlock (elf_getdata.c:447)
==15242== by 0x48A0547: __elf_getdata_rdlock (elf_getdata.c:554)
==15242== by 0x484EFB0: check_section (dwarf_begin_elf.c:167)
==15242== by 0x484F522: global_read (dwarf_begin_elf.c:310)
==15242== by 0x484F522: dwarf_begin_elf (dwarf_begin_elf.c:445)
==15242== by 0x10E690: show_symbols (nm.c:1243)
==15242== by 0x10FCEA: handle_elf (nm.c:1578)
==15242== by 0x110482: process_file (nm.c:374)
==15242== by 0x10D70D: main (nm.c:249)
==15242==
==15242== Invalid read of size 2
==15242== at 0x485094B: __libdw_next_unit (dwarf_nextcu.c:168)
==15242== by 0x4850C24: dwarf_next_unit (dwarf_nextcu.c:46)
==15242== by 0x4850C24: dwarf_nextcu (dwarf_nextcu.c:294)
==15242== by 0x10E73B: get_local_names (nm.c:627)
==15242== by 0x10E73B: show_symbols (nm.c:1285)
==15242== by 0x10FCEA: handle_elf (nm.c:1578)
==15242== by 0x110482: process_file (nm.c:374)
==15242== by 0x10D70D: main (nm.c:249)
==15242== Address 0x5254822 is 2 bytes after a block of size 32 alloc'd
==15242== at 0x483577F: malloc (vg_replace_malloc.c:299)
==15242== by 0x48A0358: convert_data (elf_getdata.c:157)
==15242== by 0x48A0358: __libelf_set_data_list_rdlock (elf_getdata.c:447)
==15242== by 0x48A0547: __elf_getdata_rdlock (elf_getdata.c:554)
==15242== by 0x484EFB0: check_section (dwarf_begin_elf.c:167)
==15242== by 0x484F522: global_read (dwarf_begin_elf.c:310)
==15242== by 0x484F522: dwarf_begin_elf (dwarf_begin_elf.c:445)
==15242== by 0x10E690: show_symbols (nm.c:1243)
==15242== by 0x10FCEA: handle_elf (nm.c:1578)
==15242== by 0x110482: process_file (nm.c:374)
==15242== by 0x10D70D: main (nm.c:249)
==15242==
We do check we can read the initial unit lenght (4 bytes), but then fail to
check if we can read any extended length for a DWARF64 unit. We also fail to
check whether we can read the actual version or (DWARF5) unit type. After we
know the version and unit type we do sanity check the full header length (we
cannot really know before reading those three fields at least).
Fixed by:
commit e8f8dc465a1fa496aa627a330886c0f70f98d4c0
Author: Mark Wielaard <mark@klomp.org>
Date: Fri Feb 1 14:03:38 2019 +0100
libdw: Check there is enough space for CU 64bit length, version and type.
We only checked we could read the initial length and after knowing the
version and type whether the unit header was the right size. Also check
there are at least enough bytes to read the 64bit length, version and
unit type bytes.
https://sourceware.org/bugzilla/show_bug.cgi?id=24140
Signed-off-by: Mark Wielaard <mark@klomp.org>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-02-01 13:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-26 8:16 [Bug libdw/24140] New: A Heap-buffer-overflow problem was discovered in the function __libdw_next_unit in dwarf_nextcu.c in libdw wcventure at 126 dot com
2019-02-01 13:10 ` [Bug libdw/24140] " mark at klomp dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).