0

I ran AFL fuzzer to open source program and I ran the program with the output crash from the fuzzing.

This is the result of address sanitizer but I am not sure what this error actually is.

ubuntu@ifn657:~/fuzz3/dact-0.8.42$ ./dact -dcf output/crashes/id:000023,sig:06,src:000013,time:312754,op:flip1,pos:20
=================================================================
==4163826==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f321f8fe80b at pc 0x000000495900 bp 0x7ffebce27520 sp 0x7ffebce26ce8
WRITE of size 747621 at 0x7f321f8fe80b thread T0
    #0 0x4958ff in __asan_memcpy (/home/ubuntu/fuzz3/dact-0.8.42/dact+0x4958ff)
    #1 0x4ce218 in comp_plain_algo /home/ubuntu/fuzz3/dact-0.8.42/comp_plain.c
    #2 0x4cc623 in dact_blk_decompress /home/ubuntu/fuzz3/dact-0.8.42/dact_common.c:176:9
    #3 0x4cc623 in dact_process_file /home/ubuntu/fuzz3/dact-0.8.42/dact_common.c:658:20
    #4 0x4d4fc1 in main /home/ubuntu/fuzz3/dact-0.8.42/dact.c:689:8
    #5 0x7f322262a0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
    #6 0x41e50d in _start (/home/ubuntu/fuzz3/dact-0.8.42/dact+0x41e50d)

0x7f321f8fe80b is located 0 bytes to the right of 524299-byte region [0x7f321f87e800,0x7f321f8fe80b)
allocated by thread T0 here:
    #0 0x49640d in malloc (/home/ubuntu/fuzz3/dact-0.8.42/dact+0x49640d)
    #1 0x4cbda1 in dact_process_file /home/ubuntu/fuzz3/dact-0.8.42/dact_common.c:581:17
    #2 0x4d4fc1 in main /home/ubuntu/fuzz3/dact-0.8.42/dact.c:689:8
    #3 0x7f322262a0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/ubuntu/fuzz3/dact-0.8.42/dact+0x4958ff) in __asan_memcpy
Shadow bytes around the buggy address:
  0x0fe6c3f17cb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe6c3f17cc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe6c3f17cd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe6c3f17ce0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe6c3f17cf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe6c3f17d00: 00[03]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe6c3f17d10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe6c3f17d20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe6c3f17d30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe6c3f17d40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe6c3f17d50: 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
  Shadow gap:              cc
==4163826==ABORTING

And where do I have to look in?

Do I have to look in main function of dact.c?

lilput
  • 71
  • 1
  • 1
  • 5
  • There are stack traces for the code that overran the buffer, and the code that allocated that buffer in the first place. Do you know how to read stack traces? – Nate Eldredge Nov 01 '20 at 05:28
  • @NateEldredge No. I'm trying to figure out how. – lilput Nov 01 '20 at 06:51
  • https://stackoverflow.com/questions/3988788/what-is-a-stack-trace-and-how-can-i-use-it-to-debug-my-application-errors may help; it's for Java but the concept is the same. – Nate Eldredge Nov 01 '20 at 21:57

0 Answers0