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.

Sign up for GitHub

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

Jump to bottom

radare2 Mach-O 64-bit crash #12973

Closed
ghost opened this issue Feb 2, 2019 · 16 comments
Closed

radare2 Mach-O 64-bit crash #12973

ghost opened this issue Feb 2, 2019 · 16 comments
Milestone
3.3.0

Comments

@ghost
Copy link

ghost commented Feb 2, 2019 •
edited by Maijin
Loading

Work environment

Questions Answers
OS/arch/bits (mandatory) macOS Mojave 10.14.3
File format of the file you reverse (mandatory) Mach-O
Architecture/bits of the file (mandatory) 64-bit executable x86_64
r2 -v full output, not truncated (mandatory) radare2 3.3.0-git 20711 @ darwin-x86-64 git.3.2.1-218-g5d698c76a
commit: 5d698c7 build: 2019-02-02__21:22:41

Expected behavior

Not crash

Actual behavior

Crash with -A

Steps to reproduce the behavior

r2 -A kernel # Mach-O macOS default kernel

`==57122==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000143680 at pc 0x000109bd2baf bp 0x7ffee96f9d70 sp 0x7ffee96f9d68
READ of size 1 at 0x619000143680 thread T0
    #0 0x109bd2bae in fcn_recurse fcn.c:1012
    #1 0x109bcdcdb in r_anal_fcn fcn.c:1648
    #2 0x106bf9730 in core_anal_fcn canal.c:710
    #3 0x106bf7444 in r_core_anal_fcn canal.c:1656
    #4 0x106c25e42 in r_core_anal_all canal.c:3565
    #5 0x106852a49 in cmd_anal_all cmd_anal.c:7587
    #6 0x1066ba237 in cmd_anal cmd_anal.c:8294
    #7 0x106bd0ed1 in r_cmd_call cmd_api.c:235
    #8 0x1067b2896 in r_core_cmd_subst_i cmd.c:3013
    #9 0x10667f3b0 in r_core_cmd_subst cmd.c:2021
    #10 0x106667699 in r_core_cmd cmd.c:3747
    #11 0x10662817e in r_core_cmd0 cmd.c:3912
    #12 0x106507f8e in main radare2.c:1381
    #13 0x7fff5f63fed8 in start (libdyld.dylib:x86_64+0x16ed8)

0x619000143680 is located 0 bytes to the right of 1024-byte region [0x619000143280,0x619000143680)
allocated by thread T0 here:
    #0 0x110c14a07 in wrap_calloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x57a07)
    #1 0x106bf8e92 in core_anal_fcn canal.c:688
    #2 0x106bf7444 in r_core_anal_fcn canal.c:1656
    #3 0x106c25e42 in r_core_anal_all canal.c:3565
    #4 0x106852a49 in cmd_anal_all cmd_anal.c:7587
    #5 0x1066ba237 in cmd_anal cmd_anal.c:8294
    #6 0x106bd0ed1 in r_cmd_call cmd_api.c:235
    #7 0x1067b2896 in r_core_cmd_subst_i cmd.c:3013
    #8 0x10667f3b0 in r_core_cmd_subst cmd.c:2021
    #9 0x106667699 in r_core_cmd cmd.c:3747
    #10 0x10662817e in r_core_cmd0 cmd.c:3912
    #11 0x106507f8e in main radare2.c:1381
    #12 0x7fff5f63fed8 in start (libdyld.dylib:x86_64+0x16ed8)

SUMMARY: AddressSanitizer: heap-buffer-overflow fcn.c:1012 in fcn_recurse
Shadow bytes around the buggy address:
  0x1c3200028680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c3200028690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c32000286a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c32000286b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c32000286c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1c32000286d0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c32000286e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c32000286f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c3200028700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c3200028710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c3200028720: 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
==57122==ABORTING
@radare
Copy link
Collaborator

radare commented Feb 2, 2019 via email

@ghost
Copy link
Author

ghost commented Feb 2, 2019

kernel.gz

@ghost
Copy link
Author

ghost commented Feb 3, 2019

Would it be possible to fix this issue ASAP please?

@radare
Copy link
Collaborator

radare commented Feb 3, 2019 via email

@ghost
Copy link
Author

ghost commented Feb 3, 2019

I am very sorry for your problems in real life. I close this issue because I do not intend to use radare2 anymore and therefore you will have more time for your real life.

@ghost ghost closed this as completed Feb 3, 2019
@radare radare reopened this Feb 3, 2019
@radare
Copy link
Collaborator

radare commented Feb 3, 2019 via email

@radare radare closed this as completed in beacb0b Feb 3, 2019
@radare
Copy link
Collaborator

radare commented Feb 3, 2019

Took me less than a minute to fix that stupid bug that only happens when running in ASAN. It's completely retarded to use r2 for real usecases built with ASAN because it NEVER frees memory and its more than 3 times slower than normal executions, even more when analyzing huge files like a kernel.

The bug is just a 1 byte read outside a buffer that is hold in the stack, the address is completely valid and no single operating system will make this crash at all.

Don't worry for my real life problems, those cant be fixed.

@ghost
Copy link
Author

ghost commented Feb 3, 2019

I just use ASAN because it also crashed while executing an "axtj" and your community suggested to send the crash stacktrace under ASAN. You are a toxic person with that kind of attitude

@radare
Copy link
Collaborator

radare commented Feb 3, 2019

😘

@radare
Copy link
Collaborator

radare commented Feb 3, 2019

and btw you didnt mentioned anything about axtj in the bug report

@radare
Copy link
Collaborator

radare commented Feb 3, 2019

I have fully analzyed this binary, and tried axj, pD, vbg, axtj, callgraph, and several other related commands without any issue at all.

Stressing out the developers and give up on using an opensource tool to solve an issue that is unrelated to your problem because you don't report it properly or you dont even understand the crashlog or you dont know how to use a debugger is not the way to go in any place.

Anyway, thanks for reporting, i have also fixed a couple of other inconsistencies I found in 5 minutes just when checking out this binary.

@ghost
Copy link
Author

ghost commented Feb 3, 2019

With that toxic attitude, it's no doubt you have problems in real life. And no, it's not fixed with your commit, you do not even understand the problem. But I do not care either, I understand why people do not want to use radare2, and it's not because bugs, it's because of that lack of humility you have.

@ghost
Copy link
Author

ghost commented Feb 3, 2019 •
edited by Maijin
Loading

cool fix bruh

ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030173444f8 at pc 0x00010e54eea5 bp 0x7ffeebe83db0 sp 0x7ffeebe83530
WRITE of size 2 at 0x6030173444f8 thread T0
    #0 0x10e54eea4 in wrap_strcat (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4fea4)
    #1 0x1040c6dd1 in cmd_anal_refs cmd_anal.c:5958
    #2 0x103f392ff in cmd_anal cmd_anal.c:8288
    #3 0x10444f0a1 in r_cmd_call cmd_api.c:235
    #4 0x10402fe0f in r_core_cmd_subst_i cmd.c:3012
    #5 0x103efe510 in r_core_cmd_subst cmd.c:2021
    #6 0x103ee6a69 in r_core_cmd cmd.c:3745
    #7 0x103e7d184 in r_core_prompt_exec core.c:2750
    #8 0x103d820a7 in main radare2.c:1463
    #9 0x7fff750cced8 in start (libdyld.dylib:x86_64+0x16ed8)

0x6030173444f8 is located 0 bytes to the right of 24-byte region [0x6030173444e0,0x6030173444f8)
allocated by thread T0 here:
    #0 0x10e5504bc in wrap_strdup (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x514bc)
    #1 0x1040c6db7 in cmd_anal_refs cmd_anal.c:5957
    #2 0x103f392ff in cmd_anal cmd_anal.c:8288
    #3 0x10444f0a1 in r_cmd_call cmd_api.c:235
    #4 0x10402fe0f in r_core_cmd_subst_i cmd.c:3012
    #5 0x103efe510 in r_core_cmd_subst cmd.c:2021
    #6 0x103ee6a69 in r_core_cmd cmd.c:3745
    #7 0x103e7d184 in r_core_prompt_exec core.c:2750
    #8 0x103d820a7 in main radare2.c:1463
    #9 0x7fff750cced8 in start (libdyld.dylib:x86_64+0x16ed8)

SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4fea4) in wrap_strcat
Shadow bytes around the buggy address:
  0x1c0602e68840: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
  0x1c0602e68850: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
  0x1c0602e68860: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x1c0602e68870: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
  0x1c0602e68880: 00 fa fa fa 00 00 00 fa fa fa fd fd fd fa fa fa
=>0x1c0602e68890: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00[fa]
  0x1c0602e688a0: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
  0x1c0602e688b0: 00 fa fa fa 00 00 00 fa fa fa fd fd fd fa fa fa
  0x1c0602e688c0: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x1c0602e688d0: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
  0x1c0602e688e0: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 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
==20212==ABORTING

@radare radare reopened this Feb 3, 2019
@radare
Copy link
Collaborator

radare commented Feb 3, 2019

I still cant reproduce, and this exact line number has been also fixed, because it is a bug recently introduced by a newbye contributor, and the line you report in there doesnt matches the code in master, can you try doing git pull?.

And about my real life problems I doubt a death of a beloved one is caused by my attitude in this PR, i'm keeping this PR open waiting for feedback.

Thanks

@condret
Copy link
Member

condret commented Feb 3, 2019

@agarciagonzalez excuse me, but i have to consider your definition "toxic" as highly questionable. If you think, replying to an issue with an explanation, why a person couldn't fix a bug immediately, is toxic, I suggest you to reconsider your own views and stay away from us, if you really think this was ok.

@radare radare added this to the 3.3.0 milestone Feb 4, 2019
@radare
Copy link
Collaborator

radare commented Feb 7, 2019

timeout

@radare radare closed this as completed Feb 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
3.3.0
Development

No branches or pull requests
2 participants
@radare @condret