there is a heap-based buffer overflow in the ReadTIFFImage function (src/coders/tiff.c), which can be triggered by the POC in the attachment with AddressSanitizer enabled.
gm convert $POC OUTPUT
==36059==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ed32 at pc 0x7f0485f37565 bp 0x7fffc6fce590 sp 0x7fffc6fcdd40
READ of size 15 at 0x60200000ed32 thread T0
#0 0x7f0485f37564 in asan_memcpy ../../../../src/libsanitizer/asan/asan_interceptors.cc:367
#1 0x9f2b65 in ReadTIFFImage (/home/youwei/ProbeFuzzer/product/graphicsmagick/master/exe_sat/bin/gm+0x9f2b65)
#2 0x4981d7 in ReadImage (/home/youwei/ProbeFuzzer/product/graphicsmagick/master/exe_sat/bin/gm+0x4981d7)
#3 0x427921 in ConvertImageCommand (/home/youwei/ProbeFuzzer/product/graphicsmagick/master/exe_sat/bin/gm+0x427921)
#4 0x443a13 in MagickCommand (/home/youwei/ProbeFuzzer/product/graphicsmagick/master/exe_sat/bin/gm+0x443a13)
#5 0x47be14 in GMCommandSingle (/home/youwei/ProbeFuzzer/product/graphicsmagick/master/exe_sat/bin/gm+0x47be14)
#6 0x47c0bc in GMCommand (/home/youwei/ProbeFuzzer/product/graphicsmagick/master/exe_sat/bin/gm+0x47c0bc)
#7 0x40d9b7 in main (/home/youwei/ProbeFuzzer/product/graphicsmagick/master/exe_sat/bin/gm+0x40d9b7)
#8 0x38c3c1ed1c in libc_start_main (/lib64/libc.so.6+0x38c3c1ed1c)
I am not able to reproduce this issue. What version of libtiff and libjpeg are being used? Is this a 64-bit or 32-bit build? Please post the full output from 'gm -version'.
This issue could easily be due to a bug already fixed in libtiff or related to a specific libjpeg distribution/version. I do see libtiff making two security-related corrections to the TIFF parsing. I also see that the file uses old JPEG compression TIFF format.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your work.
It is a 64-bt build with address sanitizer enables (CFLAGS=-fsanitize=address).
I have git pull the latest commit of libtiff and libjpeg and place the code in tiff and jpeg folders of graphicmagick source code. After complication, I can still reproduce this issue.
Did you complie with address sanitizer enabled (i.e., CFLAGS=-fsanitize=address)?
You said that you saw libtiff making two security-related corrections to the TIFF parsing. Could you please send me the references URL to these two issues. I will check whehter my issue is different from these two. Thank you .
Thanks for your work.
It is a 64-bt build with address sanitizer enables (CFLAGS=-fsanitize=address).
I have git pull the latest commit of libtiff and libjpeg and place the code in tiff and jpeg folders of graphicmagick source code. After complication, I can still reproduce this issue.
Did you complie with address sanitizer enabled (i.e., CFLAGS=-fsanitize=address)?
You need to be clear about what is meant by "libjpeg" since there are
two major "libjpeg" projects now (as well as two other splinter
projects). I am using IJG JPEG (IJG JPEG 80), which historically has
fewer anomalies than TurboJPEG. One reason why I am using IJG JPEG is
so that the GraphicsMagick test suite could pass with valgrind and
ASAN.
I tested with ASAN and valgrind.
You said that you saw libtiff making two security-related
corrections to the TIFF parsing. Could you please send me the
references URL to these two issues. I will check whehter my issue is
different from these two. Thank you .
If you add '-debug coder' to the options, you will then see many
warnings from libtiff, many of which say that it made a correction:
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Invalid TIFF directory; tags are not sorted in
ascending order.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 32781 (0x800d) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 384 (0x180) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 1093 (0x445) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 2 (0x2) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: ASCII value for tag "Tag 32781" does not end in null
byte. Forcing it to be null.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Incorrect count for "JpegProc"; tag ignored.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Photometric tag value assumed incorrect, assuming data
is YCbCr instead of RGB.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: SamplesPerPixel tag is missing, applying correct
SamplesPerPixel value of 3.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: SamplesPerPixel tag value is changing, but
SMinSampleValue tag was read with a different value. Cancelling it.
I am suspecting that the small error which was detected can be
attributed to libjpeg behavior.
Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply.
We have checked the issue carefully and found it is a bug in libtiff, which got fixed in the latest version of libtiff.
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reproducer does not declare SamplesPerPixel field, so libTIFF does some guessing to set the correct value. Unfortunately it does not update the SMinSampleValue value, leading to later crash.
It was fixed in 739dcd28 (https://gitlab.com/libtiff/libtiff/commit/739dcd28a061738b317c1e9f91029d9cbc157159)
You can reproduce the issue by building a pre-739dcd28 libTIFF with asan:
$ ./tools/tiffset ./graphicsmagic_0.tif
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 32781(0x800d) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 384(0x180) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 1093(0x445) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 2(0x2) encountered.
TIFFFetchNormalTag: Warning, Incorrect count for"JpegProc"; tag ignored.
TIFFReadDirectory: Warning, Photometric tag value assumed incorrect, assuming data is YCbCr instead of RGB.
TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, applying correct SamplesPerPixel value of 3.
===================================================================6139==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000118 at pc 0x7f56213cf283 bp 0x7ffc20a95f90 sp 0x7ffc20a95f88
READ of size 8 at 0x602000000118 thread T0
#0 0x7f56213cf282 in TIFFWriteDirectoryTagSampleformatArray /home/hle/Development/C/libtiff/libtiff/tif_dirwrite.c:994#1 0x7f56213cb352 in TIFFWriteDirectorySec /home/hle/Development/C/libtiff/libtiff/tif_dirwrite.c:577#2 0x7f56213c7f01 in TIFFWriteDirectory /home/hle/Development/C/libtiff/libtiff/tif_dirwrite.c:183#3 0x7f56213c95d8 in TIFFRewriteDirectory /home/hle/Development/C/libtiff/libtiff/tif_dirwrite.c:359#4 0x557fb2e29c1d in main /home/hle/Development/C/libtiff/tools/tiffset.c:344#5 0x7f5620772b16 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x22b16)#6 0x557fb2e282d9 in _start (/home/hle/Development/C/libtiff/tools/.libs/tiffset+0x22d9)
0x602000000118 is located 0 bytes to the right of 8-byte region [0x602000000110,0x602000000118)
allocated by thread T0 here:
#0 0x7f56215b5ed0 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)#1 0x7f562147b780 in _TIFFmalloc /home/hle/Development/C/libtiff/libtiff/tif_unix.c:316#2 0x7f562138dd55 in setByteArray /home/hle/Development/C/libtiff/libtiff/tif_dir.c:53#3 0x7f562138df41 in _TIFFsetDoubleArray /home/hle/Development/C/libtiff/libtiff/tif_dir.c:73#4 0x7f562139088e in _TIFFVSetField /home/hle/Development/C/libtiff/libtiff/tif_dir.c:279#5 0x7f5621436768 in OJPEGVSetField /home/hle/Development/C/libtiff/libtiff/tif_ojpeg.c:600#6 0x7f5621397b95 in TIFFVSetField /home/hle/Development/C/libtiff/libtiff/tif_dir.c:822#7 0x7f56213975c8 in TIFFSetField /home/hle/Development/C/libtiff/libtiff/tif_dir.c:766#8 0x7f56213ba65c in TIFFReadDirectory /home/hle/Development/C/libtiff/libtiff/tif_dirread.c:3711#9 0x7f562144a66f in TIFFClientOpen /home/hle/Development/C/libtiff/libtiff/tif_open.c:466#10 0x7f562147b4e6 in TIFFFdOpen /home/hle/Development/C/libtiff/libtiff/tif_unix.c:211#11 0x7f562147b73f in TIFFOpen /home/hle/Development/C/libtiff/libtiff/tif_unix.c:250#12 0x557fb2e285c0 in main /home/hle/Development/C/libtiff/tools/tiffset.c:86#13 0x7f5620772b16 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x22b16)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/hle/Development/C/libtiff/libtiff/tif_dirwrite.c:994 in TIFFWriteDirectoryTagSampleformatArray
Shadow bytes around the buggy address:
0x0c047fff7fd0: 00000000000000000000000000000000
0x0c047fff7fe0: 00000000000000000000000000000000
0x0c047fff7ff0: 00000000000000000000000000000000
0x0c047fff8000: fa fa 0000 fa fa fd fa fa fa fd fd fa fa 0007
0x0c047fff8010: fa fa fd fa fa fa 00 fa fa fa fd fa fa fa fd fa=>0x0c047fff8020: fa fa 00[fa]fa fa fd fa fa fa 04 fa fa fa fa fa
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8070: 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: 01020304050607
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==6139==ABORTING
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not able to reproduce this issue. What version of libtiff and libjpeg are being used? Is this a 64-bit or 32-bit build? Please post the full output from 'gm -version'.
This issue could easily be due to a bug already fixed in libtiff or related to a specific libjpeg distribution/version. I do see libtiff making two security-related corrections to the TIFF parsing. I also see that the file uses old JPEG compression TIFF format.
Thanks for your work.
It is a 64-bt build with address sanitizer enables (CFLAGS=-fsanitize=address).
I have git pull the latest commit of libtiff and libjpeg and place the code in tiff and jpeg folders of graphicmagick source code. After complication, I can still reproduce this issue.
Did you complie with address sanitizer enabled (i.e., CFLAGS=-fsanitize=address)?
You said that you saw libtiff making two security-related corrections to the TIFF parsing. Could you please send me the references URL to these two issues. I will check whehter my issue is different from these two. Thank you .
The output of ”gm -version" is like below:
GraphicsMagick 1.4 snapshot-20180107 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2018 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.
Feature Support:
Native Thread Safe yes
Large Files (> 32 bit) yes
Large Memory (> 32 bit) yes
BZIP yes
DPS no
FlashPix no
FreeType yes
Ghostscript (Library) no
JBIG no
JPEG-2000 yes
JPEG yes
Little CMS no
Loadable Modules no
OpenMP yes (201307)
PNG yes
TIFF yes
TRIO no
UMEM no
WebP yes
WMF yes
X11 yes
XML yes
ZLIB yes
Host type: x86_64-unknown-linux-gnu
Configured using the command:
/u/ProbeFuzzer/ProbeFuzzer/product/graphicsmagick/master/src/configure '--prefix=/u/ProbeFuzzer/ProbeFuzzer/product/graphicsmagick/master/exe_asan' 'CC=/u/ProbeFuzzer/ProbeFuzzer/afl/afl-gcc' 'CFLAGS=-fsanitize=address' 'LDFLAGS=-fsanitize=address' 'CXX=/u/ProbeFuzzer/ProbeFuzzer/afl/afl-g++' 'CXXFLAGS=-fsanitize=address'
Final Build Parameters:
CC = /u/ProbeFuzzer/ProbeFuzzer/afl/afl-gcc
CFLAGS = -fopenmp -fsanitize=address -Wall
CPPFLAGS = -I/usr/include/freetype2 -I/usr/include/libxml2
CXX = /u/ProbeFuzzer/ProbeFuzzer/afl/afl-g++
CXXFLAGS = -fsanitize=address
LDFLAGS = -fsanitize=address
LIBS = -lwebp -lwebpmux -ltiff -lfreetype -ljasper -ljpeg -lpng12 -lwmflite -lXext -lSM -lICE -lX11 -llzma -lbz2 -lxml2 -lz -lm -lgomp -lpthread
On Fri, 12 Jan 2018, Probe Fuzzer wrote:
You need to be clear about what is meant by "libjpeg" since there are
two major "libjpeg" projects now (as well as two other splinter
projects). I am using IJG JPEG (IJG JPEG 80), which historically has
fewer anomalies than TurboJPEG. One reason why I am using IJG JPEG is
so that the GraphicsMagick test suite could pass with valgrind and
ASAN.
I tested with ASAN and valgrind.
If you add '-debug coder' to the options, you will then see many
warnings from libtiff, many of which say that it made a correction:
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Invalid TIFF directory; tags are not sorted in
ascending order.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 32781 (0x800d) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 384 (0x180) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 1093 (0x445) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Unknown field with tag 2 (0x2) encountered.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: ASCII value for tag "Tag 32781" does not end in null
byte. Forcing it to be null.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Incorrect count for "JpegProc"; tag ignored.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: Photometric tag value assumed incorrect, assuming data
is YCbCr instead of RGB.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: SamplesPerPixel tag is missing, applying correct
SamplesPerPixel value of 3.
08:01:27 0:01 0.000u 15498 tiff.c/unknown/1007/Coder:
TIFF Warning: SamplesPerPixel tag value is changing, but
SMinSampleValue tag was read with a different value. Cancelling it.
I am suspecting that the small error which was detected can be
attributed to libjpeg behavior.
Bob
Thanks for your reply.
We have checked the issue carefully and found it is a bug in libtiff, which got fixed in the latest version of libtiff.
Thanks again.
Hi
Can you point to which libtiff upstream change did fix the issue?
Hi Bob,
what is commit that fix this issue?
Thanks!
On Thu, 28 Jun 2018, kirotawa wrote:
That is a good question since it was already fixed by the time the
problem was reported and so there is no specific change entry for this
POC.
If you really need to know, then I suggest studying the Mercurial
commits to coders/tiff.c and read the entries in the ChangeLog files.
Bob
In can confirm that this issue was a bug in the libTIFF codebase, namely http://bugzilla.maptools.org/show_bug.cgi?id=2500
The reproducer does not declare SamplesPerPixel field, so libTIFF does some guessing to set the correct value. Unfortunately it does not update the SMinSampleValue value, leading to later crash.
It was fixed in 739dcd28 (https://gitlab.com/libtiff/libtiff/commit/739dcd28a061738b317c1e9f91029d9cbc157159)
You can reproduce the issue by building a pre-739dcd28 libTIFF with asan: