Security
Headlines
HeadlinesLatestCVEs

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.

CVE
#ubuntu#linux#git

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.

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907