Target location setting for CVE-2017-8392 is different from AFLGo and CVE Report

[zu1k]

Congratulation on your outstanding work and the publication of your paper.

I have come across an issue regarding the target location setting for vulnerability number cve-2017-8392. It appears to be inconsistent with the descriptions in both the AFLGo script and the CVE report. Additionally, the provided PoC and the backtrace from the execution do not seem to match the details in the CVE report.

I'm wondering if perhaps this is a different vulnerability? If so, could you kindly inform me of the correct vulnerability number? This information would greatly assist me in my understanding and further research.

[goodtaeeun]

Hi, thank you for your interest in our artifact. In short, we did target cve-2017-8392.

The target line and the backtrace are different from the cve report mainly because of two reasons.

1. The stack trace we obtained in our environment was slightly different from the one in the cve report. Here is the ASAN Log from the PoC input executed in our environment.

   
   ==272==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000000072 at pc 0x0000005e3f9d bp 0x7ffce283a7a0 sp 0x7ffce283a798
   READ of size 1 at 0x608000000072 thread T0
   #0 0x5e3f9c in bfd_getl32 /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/libbfd.c:548:23
   #1 0x77599d in read_4_bytes /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/./dwarf2.c:597:10
   #2 0x775cc0 in parse_comp_unit /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/./dwarf2.c:2960:21
   #3 0x773c2d in _bfd_dwarf2_find_nearest_line /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/./dwarf2.c:4291:11
   #4 0x69e246 in _bfd_elf_find_nearest_line /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/elf.c:8565:7
   #5 0x4deada in show_line /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:1434:9
   #6 0x4dc1f8 in disassemble_bytes /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:1728:6
   #7 0x4d855a in disassemble_section /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:2241:7
   #8 0x5ef36a in bfd_map_over_sections /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/section.c:1395:5
   #9 0x4cf0ea in disassemble_data /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:2375:3
   #10 0x4cb430 in dump_bfd /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3469:5
   #11 0x4cab8f in display_object_bfd /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3526:7
   #12 0x4caa8d in display_any_bfd /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3615:5
   #13 0x4ca625 in display_file /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3636:3
   #14 0x4c9f3d in main /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3919:4
   #15 0x7f3e6a85a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
   #16 0x41c53d in _start (/benchmark/bin/ASAN/objdump-2017-8392+0x41c53d)

0x608000000072 is located 0 bytes to the right of 82-byte region [0x608000000020,0x608000000072) allocated by thread T0 here:

0 0x49725d in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3

#1 0x5e3335 in bfd_malloc /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/libbfd.c:184:9
#2 0x76ae9a in read_section /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/./dwarf2.c:542:35
#3 0x767d8d in _bfd_dwarf2_slurp_debug_info /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/./dwarf2.c:3971:13
#4 0x772920 in _bfd_dwarf2_find_nearest_line /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/./dwarf2.c:4115:9
#5 0x69e246 in _bfd_elf_find_nearest_line /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/elf.c:8565:7
#6 0x4deada in show_line /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:1434:9
#7 0x4dc1f8 in disassemble_bytes /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:1728:6
#8 0x4d855a in disassemble_section /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:2241:7
#9 0x5ef36a in bfd_map_over_sections /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/section.c:1395:5
#10 0x4cf0ea in disassemble_data /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:2375:3
#11 0x4cb430 in dump_bfd /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3469:5
#12 0x4cab8f in display_object_bfd /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3526:7
#13 0x4caa8d in display_any_bfd /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3615:5
#14 0x4ca625 in display_file /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3636:3
#15 0x4c9f3d in main /benchmark/RUNDIR-binutils-2.28/binutils-2.28/binutils/./objdump.c:3919:4
#16 0x7f3e6a85a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /benchmark/RUNDIR-binutils-2.28/binutils-2.28/bfd/libbfd.c:548:23 in bfd_getl32 Shadow bytes around the buggy address: 0x0c107fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c107fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c107fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c107fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c107fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c107fff8000: fa fa fa fa 00 00 00 00 00 00 00 00 00 00[02]fa 0x0c107fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8050: 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 ==272==ABORTING

This stack trace shows three more functions than the stack trace in the CVE report (excluding malloc).
We have set the final crashing point in the stack trace obtained in our environment as the target site.

2. The version of the target code is slightly different. This is why the overall line numbers differ slightly from the original report.

I hope this clarifies your question.

Regards,
Tae Eun.

[zu1k]

Thanks for the explanation, but I still have two questions.

It looks like the PoC you provided is not one of the two PoCs attached to the issue tracker, can you provide the source of the PoC?

And the vulnerability type in the vulnerability report is caused by a null pointer dereference, but the backtrace you provided is a heap overflow vulnerability, could you please explain it further.

[goodtaeeun]

1. The POC we provide is the first POC listed in the issue report, named bug_7. Try md5sum on the two files and you will get the same hash number.

2. After examination, it seems like I have misclassified the crash as cve-2017-8392. I tried to find some other CVE that is relevant to the above stack trace but could not find one. Thank you for pointing it out and I am sorry for the confusion.

[zu1k]

1. The POC we provide is the first POC listed in the issue report, named bug_7. Try md5sum on the two files and you will get the same hash number.

I'm very sorry I was misled by the file size shown, the PoC is indeed the PoC for this cve.

2. After examination, it seems like I have misclassified the crash as cve-2017-8392. I tried to find some other CVE that is relevant to the above stack trace but could not find one. Thank you for pointing it out and I am sorry for the confusion.

Congratulations, this should be a new CVE.

[zu1k]

Thank you very much for your answers, I'm going to close this issue, please do let me know if there are any new developments.