Bug 1524104 - exiv2 library: heap-based buffer over-read in Exiv2::Image::byteSwap4 (image.cpp)
exiv2 library: heap-based buffer over-read in Exiv2::Image::byteSwap4 (image....
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: exiv2 (Show other bugs)
7.5-Alt
Unspecified Linux
unspecified Severity urgent
: rc
: ---
Assigned To: Jan Grulich
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-10 00:43 EST by Wei You
Modified: 2017-12-10 00:43 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
poc to trigger the vulnerability (22 bytes, image/tiff)
2017-12-10 00:43 EST, Wei You
no flags Details

  None (edit)
Description Wei You 2017-12-10 00:43:31 EST
Created attachment 1365482 [details]
poc to trigger the vulnerability

on 0.26 (the latest version):

there is a heap-based buffer over-read in the Exiv2::Image::byteSwap4 function (src/image.cpp), which can be triggered by poc_0.tiff in the
attachment.

Note that this vulnerability exists in the exiv2 library, any software using
exiv2 will be affected by this vulnerability. Remote attackers can exploit
this vulnerability to disclose memory data or cause a denial of service via a crafted tiff file.

As a demonstration, please run the following command-line to trigger this
vulnerability:


./0.26/bin/exiv2 poc_0.tiff 
=================================================================
==11745==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ed80 at pc 0x000000620b4d bp 0x7ffccda7af80 sp 0x7ffccda7af70
READ of size 1 at 0x60200000ed80 thread T0
    #0 0x620b4c in Exiv2::Image::byteSwap4(Exiv2::DataBuf&, unsigned long, bool) /home/fuzz/exiv2/0.26/src/image.cpp:269
    #1 0x620b4c in Exiv2::Image::printIFDStructure(Exiv2::BasicIo&, std::ostream&, Exiv2::PrintStructureOption, unsigned int, bool, char, int) /home/fuzz/exiv2/0.26/src/image.cpp:444
    #2 0x622035 in Exiv2::Image::printTiffStructure(Exiv2::BasicIo&, std::ostream&, Exiv2::PrintStructureOption, int, unsigned long) /home/fuzz/exiv2/0.26/src/image.cpp:517
    #3 0x7ea794 in Exiv2::TiffImage::printStructure(std::ostream&, Exiv2::PrintStructureOption, int) /home/fuzz/exiv2/0.26/src/tiffimage.cpp:348
    #4 0x7fa25d in Exiv2::TiffImage::readMetadata() /home/fuzz/exiv2/0.26/src/tiffimage.cpp:191
    #5 0x4f2ea6 in Action::Print::printSummary() /home/fuzz/exiv2/0.26/src/actions.cpp:289
    #6 0x4f7907 in Action::Print::run(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/fuzz/exiv2/0.26/src/actions.cpp:244
    #7 0x409cec in main /home/fuzz/exiv2/0.26/src/exiv2.cpp:170
    #8 0x7f795525182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #9 0x48f718 in _start (/home/fuzz/exiv2/0.26/bin/exiv2+0x48f718)

0x60200000ed80 is located 0 bytes to the right of 16-byte region [0x60200000ed70,0x60200000ed80)
allocated by thread T0 here:
    #0 0x7f79565956b2 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x996b2)
    #1 0x61cbc3 in Exiv2::DataBuf::DataBuf(long) ../include/exiv2/types.hpp:204
    #2 0x61cbc3 in Exiv2::Image::printIFDStructure(Exiv2::BasicIo&, std::ostream&, Exiv2::PrintStructureOption, unsigned int, bool, char, int) /home/fuzz/exiv2/0.26/src/image.cpp:402
    #3 0x622035 in Exiv2::Image::printTiffStructure(Exiv2::BasicIo&, std::ostream&, Exiv2::PrintStructureOption, int, unsigned long) /home/fuzz/exiv2/0.26/src/image.cpp:517
    #4 0x7ea794 in Exiv2::TiffImage::printStructure(std::ostream&, Exiv2::PrintStructureOption, int) /home/fuzz/exiv2/0.26/src/tiffimage.cpp:348

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/fuzz/exiv2/0.26/src/image.cpp:269 Exiv2::Image::byteSwap4(Exiv2::DataBuf&, unsigned long, bool)
Shadow bytes around the buggy address:
  0x0c047fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00 00
=>0x0c047fff9db0:[fa]fa 00 fa fa fa 00 fa fa fa 00 fa fa fa fd fd
  0x0c047fff9dc0: fa fa 06 fa fa fa 00 04 fa fa 00 04 fa fa 00 04
  0x0c047fff9dd0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
  0x0c047fff9de0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
  0x0c047fff9df0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa fd fa
  0x0c047fff9e00: 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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==11745==ABORTING

Note You need to log in before you can comment on or make changes to this bug.