Headline
CVE-2021-43814: Heap-based OOB write when parsing dwarf die info · Issue #2083 · rizinorg/rizin
Rizin is a UNIX-like reverse engineering framework and command-line toolset. In versions up to and including 0.3.1 there is a heap-based out of bounds write in parse_die() when reversing an AMD64 ELF binary with DWARF debug info. When a malicious AMD64 ELF binary is opened by a victim user, Rizin may crash or execute unintended actions. No workaround are known and users are advised to upgrade.
Work environment
Questions
Answers
OS/arch/bits (mandatory)
Ubuntu 20.04 amd64
File format of the file you reverse (mandatory)
ELF64
Architecture/bits of the file (mandatory)
amd64
rizin -v
full output, not truncated (mandatory)
rizin 0.4.0-git @ linux-x86-64 commit: 5b6aaed, build: 2021-12-09__11:19:29
Expected behavior
Analyzing binaries shouldn’t trigger an OOB memory write.
Actual behavior
There is a heap-based out of bounds write in parse_die
when reversing an amd64 elf binary with dwarf debug info, respectively.
Steps to reproduce the behavior
Analyze the binary attached below with aaa on an asan build to reproduce the crash.
binary.zip
Additional Logs, screenshots, source code, configuration dump, …
$ LD_LIBRARY_PATH=/home/faraday/rizin_dyn_asan/lib/x86_64-linux-gnu/ /home/faraday/rizin_dyn_asan/bin/rizin -TQA crashes/id\:000031\,sig\:11\,src\:028821\,time\:410419260\,op\:ext_AO\,pos\:17016
=================================================================
==61456==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200001df71 at pc 0x7f0e89427f2d bp 0x7ffcce5e6df0 sp 0x7ffcce5e6598
WRITE of size 40 at 0x60200001df71 thread T0
#0 0x7f0e89427f2c (/lib/x86_64-linux-gnu/libasan.so.5+0x67f2c)
#1 0x7f0e85fb9f99 in parse_die ../librz/bin/dwarf.c:1730
#2 0x7f0e85fbaad3 in parse_comp_unit ../librz/bin/dwarf.c:1822
#3 0x7f0e85fbbdb4 in parse_info_raw ../librz/bin/dwarf.c:1955
#4 0x7f0e85fbcebe in rz_bin_dwarf_parse_info ../librz/bin/dwarf.c:2109
#5 0x7f0e857f436c in rz_core_bin_apply_dwarf ../librz/core/cbin.c:694
#6 0x7f0e857f103f in rz_core_bin_apply_info ../librz/core/cbin.c:316
#7 0x7f0e857f1611 in rz_core_bin_apply_all_info ../librz/core/cbin.c:369
#8 0x7f0e85848fc3 in rz_core_file_do_load_for_io_plugin ../librz/core/cfile.c:712
#9 0x7f0e8584afed in rz_core_bin_load ../librz/core/cfile.c:940
#10 0x7f0e8905abdd in rz_main_rizin ../librz/main/rizin.c:1128
#11 0x55a1564cd9bd in main ../binrz/rizin/rizin.c:57
#12 0x7f0e88e650b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#13 0x55a1564cd2ed in _start (/home/faraday/rizin_dyn_asan/bin/rizin+0x22ed)
0x60200001df71 is located 0 bytes to the right of 1-byte region [0x60200001df70,0x60200001df71)
allocated by thread T0 here:
#0 0x7f0e894cddc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
#1 0x7f0e85fb5b47 in init_die ../librz/bin/dwarf.c:1223
#2 0x7f0e85fba990 in parse_comp_unit ../librz/bin/dwarf.c:1816
#3 0x7f0e85fbbdb4 in parse_info_raw ../librz/bin/dwarf.c:1955
#4 0x7f0e85fbcebe in rz_bin_dwarf_parse_info ../librz/bin/dwarf.c:2109
#5 0x7f0e857f436c in rz_core_bin_apply_dwarf ../librz/core/cbin.c:694
#6 0x7f0e857f103f in rz_core_bin_apply_info ../librz/core/cbin.c:316
#7 0x7f0e857f1611 in rz_core_bin_apply_all_info ../librz/core/cbin.c:369
#8 0x7f0e85848fc3 in rz_core_file_do_load_for_io_plugin ../librz/core/cfile.c:712
#9 0x7f0e8584afed in rz_core_bin_load ../librz/core/cfile.c:940
#10 0x7f0e8905abdd in rz_main_rizin ../librz/main/rizin.c:1128
#11 0x55a1564cd9bd in main ../binrz/rizin/rizin.c:57
#12 0x7f0e88e650b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0x67f2c)
Shadow bytes around the buggy address:
0x0c047fffbb90: fa fa fd fa fa fa fa fa fa fa fd fa fa fa fa fa
0x0c047fffbba0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fa fa
0x0c047fffbbb0: fa fa fd fa fa fa fa fa fa fa fd fd fa fa fd fa
0x0c047fffbbc0: fa fa fa fa fa fa fd fa fa fa fa fa fa fa fd fa
0x0c047fffbbd0: fa fa fa fa fa fa fd fa fa fa fa fa fa fa fd fa
=>0x0c047fffbbe0: fa fa fa fa fa fa fd fa fa fa fd fd fa fa[01]fa
0x0c047fffbbf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
0x0c047fffbc00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
0x0c047fffbc10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
0x0c047fffbc20: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fd
0x0c047fffbc30: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
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
Shadow gap: cc
==61456==ABORTING
The issue seems to be that at dwarf.c:1223
the line die->attr_values = calloc(sizeof(RzBinDwarfAttrValue), attr_count);
gets executed with attr_count
equal to 0, so this is equivalent to a malloc(0)
(I think in this case a chunk with the smallest allocatable size is returned, which should be around 16 or 32 bytes, but in dwarf.c:1730
a die_attribute gets written, which is 40 bytes in size).
This happens because in dwarf.c:1729
the loop gets run attr_count - 1
times, but as abbrev->count
is 0 and is of type size_t
this results in an undeflow which then triggers the OOB write.