Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heap-based OOB write when parsing dwarf die info #2083

Closed
OctavioGalland opened this issue Dec 9, 2021 · 4 comments · Fixed by #2086
Closed

Heap-based OOB write when parsing dwarf die info #2083

OctavioGalland opened this issue Dec 9, 2021 · 4 comments · Fixed by #2086

Comments

@OctavioGalland
Copy link

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.

@thestr4ng3r
Copy link
Member

@OctavioGalland can we add this binary to our test suite? https://github.com/rizinorg/rizin-testbins

@OctavioGalland
Copy link
Author

@thestr4ng3r sure!

@thestr4ng3r
Copy link
Member

Thanks. Can you confirm it is fixed on dev?

@OctavioGalland
Copy link
Author

Yes, it doesn't crash anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants