AddressSanitizer: heap-buffer-overflow in RafImage::readMetadata

[cuanduo]

Describe the bug
in my research , a heap overflow found in RafImage::readMetadata rafimage.cpp:296.

To Reproduce
exiv2 -pv $poc
exiv2poc.zip

Expected behavior

root@ubuntu:~/fuzz/exiv2# /home/tim/exiv2-asan/build/bin/exiv2  /home/tim/fuzz/exiv2/out/master/queue/id:000174,src:000124,op:ext_AO,pos:24,+cov
=================================================================
==108944==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030000001b4 at pc 0x7f55a6829733 bp 0x7ffeff406e20 sp 0x7ffeff4065c8
READ of size 4 at 0x6030000001b4 thread T0
    #0 0x7f55a6829732  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732)
    #1 0x7f55a5dc4723 in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
    #2 0x7f55a5dc4723 in Exiv2::MemIo::read(unsigned char*, unsigned long) /home/tim/exiv2-asan/src/basicio.cpp:1354
    #3 0x7f55a5f65c98 in Exiv2::RafImage::readMetadata() /home/tim/exiv2-asan/src/rafimage.cpp:296
    #4 0x7f55a5f0fa9c in Exiv2::PgfImage::readMetadata() /home/tim/exiv2-asan/src/pgfimage.cpp:153
    #5 0x5636c0fbc644 in Action::Print::printSummary() /home/tim/exiv2-asan/src/actions.cpp:260
    #6 0x5636c0fc1304 in Action::Print::run(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/tim/exiv2-asan/src/actions.cpp:215
    #7 0x5636c0f39692 in main /home/tim/exiv2-asan/src/exiv2.cpp:77
    #8 0x7f55a526db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #9 0x5636c0f3a359 in _start (/home/tim/exiv2-asan/build/bin/exiv2+0x18359)

0x6030000001b4 is located 12 bytes to the right of 24-byte region [0x603000000190,0x6030000001a8)
allocated by thread T0 here:
    #0 0x7f55a6890458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f55a5eb05e9 in Exiv2::ImageFactory::open(unsigned char const*, unsigned long) /home/tim/exiv2-asan/src/image.cpp:902

SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732) 
Shadow bytes around the buggy address:
  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff8000: fa fa fd fd fd fd fa fa 00 00 00 06 fa fa fd fd
  0x0c067fff8010: fd fa fa fa fd fd fd fd fa fa fd fd fd fd fa fa
  0x0c067fff8020: 00 00 00 00 fa fa 00 00 00 fa fa fa 00 00 00 06
=>0x0c067fff8030: fa fa 00 00 00 fa[fa]fa fa fa fa fa fa fa fa fa
  0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8080: 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
==108944==ABORTING

Desktop (please complete the following information):

• ubuntu18
• gcc 7.4.0
• -fsanitize=address -g

[piponazo]

As in #954, I could not reproduce the issue on master nor in 0.27-maintenance. I tried with gcc 7 and 8, and clang 6, using address sanitizer and release and debug modes ... am I missing something ?

[cuanduo]

As in #954, I could not reproduce the issue on master nor in 0.27-maintenance. I tried with gcc 7 and 8, and clang 6, using address sanitizer and release and debug modes ... am I missing something ?

in master
and version the day 7.12 i test
git checkout -b c4f8561

[piponazo]

I'm closing this after the findings in #953

[kirotawa]

It was assigned CVE-2019-14368 number for this issue.