FLIF crash with specific image: heap-buffer-overflow

fouzhe commented 6 years ago

Hi, all. This PAM image file can cause crash. It can cause heap-buffer-overflow. Here is ASAN result and I attached the file.

Thanks.

Execute the following command:

./flif --overwrite -e id\:000009\,sig\:06\,src\:000000\,op\:flip1\,pos\:39 2.flif

ASAN result:

Warning: expected ".png", ".pnm" or ".pam" file name extension for input file, trying anyway...
=================================================================
==17011==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b0000040c0 at pc 0x00000060ceed bp 0x7ffd4a59bad0 sp 0x7ffd4a59bac8
WRITE of size 4 at 0x61b0000040c0 thread T0
    #0 0x60ceec in TransformPaletteC<FileIO>::process(ColorRanges const*, std::vector<Image, std::allocator<Image> > const&) /home/fouzhe/my_fuzz/FLIF/src/transform/palette_C.hpp:130:112
    #1 0x775220 in bool flif_encode<FileIO>(FileIO&, std::vector<Image, std::allocator<Image> >&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, flif_options&) /home/fouzhe/my_fuzz/FLIF/src/flif-enc.cpp:914:22
    #2 0x53082a in encode_flif(int, char**, std::vector<Image, std::allocator<Image> >&, flif_options&) /home/fouzhe/my_fuzz/FLIF/src/flif.cpp:344:12
    #3 0x53bed0 in handle_encode(int, char**, std::vector<Image, std::allocator<Image> >&, flif_options&) /home/fouzhe/my_fuzz/FLIF/src/flif.cpp:360:12
    #4 0x53bed0 in main /home/fouzhe/my_fuzz/FLIF/src/flif.cpp:763
    #5 0x7f3b72d8882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #6 0x427418 in _start (/home/fouzhe/my_fuzz/FLIF/src/flif+0x427418)

Address 0x61b0000040c0 is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/fouzhe/my_fuzz/FLIF/src/transform/palette_C.hpp:130:112 in TransformPaletteC<FileIO>::process(ColorRanges const*, std::vector<Image, std::allocator<Image> > const&)
Shadow bytes around the buggy address:
  0x0c367fff87c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff87d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff87e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff87f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff8800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c367fff8810: fa fa fa fa fa fa fa fa[fa]fa fa fa fa fa fa fa
  0x0c367fff8820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff8830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff8840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff8850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fff8860: 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

fouzhe commented 6 years ago

This issue got assigned CVE-2018-12109

hongxuchen commented 6 years ago

This seems a duplicate to #502, #506 or the root cause is somewhat relevant.

fgeek commented 6 years ago

Yep, looks duplicate to me.

@fouzhe since you are fuzzing with afl you should minimize the crashing files as it's easier to analyze and use it as a test case:

AFL_TMIN_EXACT=1 afl-tmin

You need to use AFL_TMIN_EXACT option or otherwise you might end up having different crash as output.

grinapo commented 5 years ago

Just a friendly message passing: all flif code is being removed from Debian due to open and unfixed security issues (this one as well as several others): bug 903600

jonsneyers commented 3 years ago

Oops, thanks for the message passing, I guess I have been neglecting to maintain FLIF ever since work on JPEG XL started to get serious.

Probably a bit unnecessary to still fix all the fuzzerbugs in flif; it's superseded as a codec anyway.

grinapo commented 3 years ago

It's your kid, not mine :grin: but until JPEG-XL gets released some people still use FLIF so at least the security errors would be prudent to be fixed. (And even after that: I am not sure JPEG-XL will handle old flif files.)

jonsneyers commented 3 years ago

JPEG XL will certainly not handle old flif files, so yes, you'll still need flif to decode them to something cjxl can encode, if you want to convert them.

Is this issue fixed with #532?

FLIF-hub / FLIF

FLIF crash with specific image: heap-buffer-overflow #513