heap-buffer-overflow in ok_png_read_data
tianxiaogu opened this issue · 5 comments
tianxiaogu commented
Using the Decode PNG with the attached file we can easily find a heap-buffer-overflow.
=================================================================
==9877==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040000000f1 at pc 0x0000004e3a9c bp 0x7ffd68111290 sp 0x7ffd68110a40
WRITE of size 134217733 at 0x6040000000f1 thread T0
#0 0x4e3a9b in __asan_memset /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:27
#1 0x52bf24 in ok_png_read_data /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:814:17
#2 0x52bf24 in ok_png_decode2 /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:925
#3 0x52bf24 in ok_png_decode /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:981
#4 0x526274 in ok_png_read /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:159:12
#5 0x52609d in main /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/fuzzer_png.c:6:21
#6 0x7f33ff5b5b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#7 0x41a739 in _start (/home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/fuzzer_png+0x41a739)
0x6040000000f1 is located 0 bytes to the right of 33-byte region [0x6040000000d0,0x6040000000f1)
allocated by thread T0 here:
#0 0x4e4a67 in malloc /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x529a2a in ok_png_read_data /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:756:34
#2 0x529a2a in ok_png_decode2 /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:925
#3 0x529a2a in ok_png_decode /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:981
#4 0x526274 in ok_png_read /home/t/Projects/afl/fuzzing-experiments/subjects/ok-file-formats/ok_png.c:159:12
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:27 in __asan_memset
Shadow bytes around the buggy address:
0x0c087fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c087fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c087fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c087fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c087fff8000: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 07
=>0x0c087fff8010: fa fa 00 00 00 00 01 fa fa fa 00 00 00 00[01]fa
0x0c087fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8060: 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
==9877==ABORTING
brackeen commented
Thank you for the bug report, it is appreciated.
This is now fixed in 3caaeef
Is it okay if I include the "77" image as part of the test suite?
tianxiaogu commented
Hi @brackeen , yes, you can include it at your will. Actually, we have used our fuzzer to find many bugs of the library. You can also use AFL to test your code.
brackeen commented
Good to know, I will check it out.
brackeen commented
I used AFL for testing and fixed a couple issues in commit 3fdbf00
There were two issues that I saw:
- PNG files with missing headers (or data chunks that came before the header)
- PNG files with large image widths
tianxiaogu commented
Hi @brackeen , thanks for the update. AFL uses the edge coverage to identify unique crashes. So the reported "unique crash" may actually be duplicated bugs.