#739 Attempts to access uninitialized memory addresses

[yukaizhao]

Version

GraphicsMagick 1.3.43

Environment

Ubuntu 20.04.6 LTS

Command

Compile test program with address sanitizer with this command:

$ export CXX=`which clang++`
$ export CC=`which clang`
$ export CFLAGS='-g -fsanitize=address -O1 -fno-omit-frame-pointer '
$ export CXXFLAGS='-g -fsanitize=address -O1 -fno-omit-frame-pointer '
$ ./configure --disable-shared
$ make

Result

Information obtained by using ASAN:

$ ./gm convert /home/local/issue/heap-buffer-overflow-GraphicsMagick-3 out.tif

AddressSanitizer:DEADLYSIGNAL
=================================================================
==661393==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000006 (pc 0x1555553f3a2d bp 0x7fffffff9550 sp 0x7fffffff9540 T0)
==661393==The signal is caused by a READ memory access.
==661393==Hint: address points to the zero page.
    #0 0x1555553f3a2d in countInkNamesString /home/libtiff/libtiff/tif_dir.c:202:35
    #1 0x1555553e48fe in _TIFFVSetField /home/libtiff/libtiff/tif_dir.c:577:29
    #2 0x15555545843b in JPEGVSetField /home/libtiff/libtiff/tif_jpeg.c
    #3 0x1555553e1b81 in TIFFVSetField /home/libtiff/libtiff/tif_dir.c:1208:18
    #4 0x1555553e1ad8 in TIFFSetField /home/libtiff/libtiff/tif_dir.c:1152:14
    #5 0x87c9b2 in CheckAndStoreStr /home/local/asan/GraphicsMagick-1.3.43/coders/tiff.c:4474:14
    #6 0x87c534 in AddIFDExifFields /home/local/asan/GraphicsMagick-1.3.43/coders/tiff.c
    #7 0x87bc52 in AddExifFields /home/local/asan/GraphicsMagick-1.3.43/coders/tiff.c:4784:10
    #8 0x873e90 in WriteTIFFImage /home/local/asan/GraphicsMagick-1.3.43/coders/tiff.c:6214:13
    #9 0x55ee71 in WriteImage /home/local/asan/GraphicsMagick-1.3.43/magick/constitute.c:2324:14
    #10 0x55f6eb in WriteImages /home/local/asan/GraphicsMagick-1.3.43/magick/constitute.c:2483:21
    #11 0x517bde in ConvertImageCommand /home/local/asan/GraphicsMagick-1.3.43/magick/command.c:6269:11
    #12 0x52f9ef in MagickCommand /home/local/asan/GraphicsMagick-1.3.43/magick/command.c:9016:17
    #13 0x544842 in GMCommandSingle /home/local/asan/GraphicsMagick-1.3.43/magick/command.c:17655:10
    #14 0x54456f in GMCommand /home/local/asan/GraphicsMagick-1.3.43/magick/command.c:17708:16
    #15 0x4ff5d8 in main /home/local/asan/GraphicsMagick-1.3.43/utilities/gm.c:61:10
    #16 0x155554a51082 in __libc_start_main /build/glibc-wuryBv/glibc-2.31/csu/../csu/libc-start.c:308:16
    #17 0x4250ad in _start (/home/local/asan/GraphicsMagick-1.3.43/utilities/gm+0x4250ad)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/libtiff/libtiff/tif_dir.c:202:35 in countInkNamesString
==661393==ABORTING

Description

During the invocation of the TIFFSetField() function within the libtiff library by the CheckAndStoreStr() function, the countInkNamesString() function in libtiff attempts to access uninitialized memory addresses. This seems to be related to a previously patched vulnerability in libtiff. However, it has been observed that this vulnerability persists in the patched version and impacts GraphicsMagick.

[Jaroslav Fojtik]

The previous problem has been fixed recently.

I see no crash but this:

O:\src\GraphicsMagick\VisualMagick\bin\gm.exe convert heap-buffer-overflow-GraphicsMagick-3.bmp heap-buffer-overflow-GraphicsMagick-3.tiff 
Corrupt JPEG data: 44 extraneous bytes before marker 0xe1 (blob-0236ADF4x)
08:54:47 0:0.011365  0.016u 8172 tiff.c/TIFFWriteErrors/979/Coder/Error:
Warning heap-buffer-overflow-GraphicsMagick-3.tiff; Tag InkNames:
Value 657 of NumberOfInks is different from the SamplesPerPixel value 3. (_TIFFVSetField)
08:54:47 0:0.026787  0.016u 8172 tiff.c/TIFFWriteErrors/979/Coder/Error:
Ignored: Warning heap-buffer-overflow-GraphicsMagick-3.tiff; Tag InkNames:
Value 657 of NumberOfInks is different from the SamplesPerPixel value 3. (_TIFFVSetField)
O:\src\GraphicsMagick\VisualMagick\bin\gm.exe convert: Warning heap-buffer-overflow-GraphicsMagick-3.tiff; Tag InkNames:
Value 657 of NumberOfInks is different from the SamplesPerPixel value 3. (_TIFFVSetField).

This has something to do with LibTIFF. Debug build works fine, but realease build crashes:

09:10:51 0:0.010930  0.016u 13720 tiff.c/WriteTIFFImage/6196/Coder/Event:
  Resolution 96x96 pixels per inch
09:10:51 0:0.010955  0.016u 13720 tiff.c/AddIFDExifFields/4532/Coder/Event:
  Extracted tag from EXIF 14dh, Field 2, Long2 6, val 2122 InkNames
O:\src\GraphicsMagick\VisualMagick\bin\gm.exe convert: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I can blacklist InkNames tag to hide this problem. This should be fixed in LibTIFF not in gm.

[Jaroslav Fojtik]

Please note that even disabling writing EXIF tags to TIFF would not solve this libtiff problem. This problem has been hidden in LibTIFF like skeleton in a box and could be triggered from elsewhere.

InkNames is described here: https://www.awaresystems.be/imaging/tiff/tifftags/inknames.html
And the function
TIFFSetField(tiff, Tag, String);
is called with Tag=333 and string is empty

0x028E019C  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 61 6c 61 69 6e 00 00 05 90  ...............alain....
0x028E01B4  03 00 02 00 00 00 14 00 00 10 9e 90 04 00 02 00 00 00 14 00 00 10 b2 92  ..........ž...........˛’
0x028E01CC  91 00 02 00 00 00 03 37 38 00 00 92 92 00 02 00 00 00 03 37 38 00 00 ea  ‘......78..’’......78..ę

Empty string should never harm caller.

[Jaroslav Fojtik]

https://sourceforge.net/p/graphicsmagick/code/ci/8f10e02ccd6d39b747d3673b8f9993cee61956c2/tree/coders/tiff.c?diff=f3db079b2b558d321d29405222cce14834dba12a
No crash observed:

O:\temp\39>gm convert heap-buffer-overflow-GraphicsMagick-3.bmp heap-buffer-overflow-GraphicsMagick-3.tiff d:\program files\graphicsmagick-1.4-q8\gm.exe convert: Warning heap-buffer-overflow-GraphicsMagick-3.tiff; Tag InkNames: Value 6 of NumberOfInks is different from the SamplesPerPixel value 3. (_TIFFVSetField).

[Bob Friesenhahn]

Even after fixes, I am seeing many issues. I am re-opening this issue. Please do not close this issue until it is independently verified.

[Jaroslav Fojtik]

It seems to me that the patch proposed fully fixes this issue - no segfault.

There is another issue in JPG reader that causes that it reads incomplete EXIF blob. This problem has low impact, because only uninitialised value is touched. It causes no crash.

[Jaroslav Fojtik]

You should close both 738 & 739 - this creates complete mess. All remaining problems are a same and stems from JPG reader.

[Bob Friesenhahn]

The problems I am seeing are not in the JPEG reader

==311556== Invalid read of size 1
==311556==    at 0x384FEA: LD_UINT32_HI (tiff.c:4435)
==311556==    by 0x385332: AddIFDExifFields (tiff.c:4533)
==311556==    by 0x38613A: AddExifFields (tiff.c:4791)
==311556==    by 0x388BAF: WriteTIFFImage (tiff.c:6221)
==311556==    by 0x164F6A: WriteImage (constitute.c:2324)
==311556==    by 0x165629: WriteImages (constitute.c:2483)
==311556==    by 0x131F38: ConvertImageCommand (command.c:6303)
==311556==    by 0x139843: MagickCommand (command.c:9055)
==311556==    by 0x154A4D: GMCommandSingle (command.c:17712)
==311556==    by 0x154B7C: GMCommand (command.c:17765)
==311556==    by 0x11D7FC: main (gm.c:61)
==311556==  Address 0x88804b2 is 0 bytes after a block of size 4,370 alloc'd
==311556==    at 0x483B723: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==311556==    by 0x483E017: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==311556==    by 0x1993C2: _MagickReallocateResourceLimitedMemory (memory.c:818)
==311556==    by 0x199574: _MagickAllocateResourceLimitedMemory (memory.c:909)
==311556==    by 0x198C73: MagickMapCopyResourceLimitedBlob (map.c:1316)
==311556==    by 0x197734: MagickMapAllocateObject (map.c:168)
==311556==    by 0x197ACC: MagickMapAddEntry (map.c:331)
==311556==    by 0x1B0724: SetImageProfile (profile.c:1263)
==311556==    by 0x2B0DD2: ReadJPEGImage (jpeg.c:1653)
==311556==    by 0x163713: ReadImage (constitute.c:1682)
==311556==    by 0x3D74FF: BlobToImage (blob.c:786)
==311556==    by 0x25DE1C: ExtractNestedBlob (bmp.c:578)

[Jaroslav Fojtik]

Look at this text posted more carefully. Memory accessed has been allocated, but not initialised in JPG reader. You are bloating both 738 & 739 with a same problem of JPG reader.

Valgrind reports that memory is allocated by JPG reader:
**==311556== Address 0x88804b2 is 0 bytes after a block of size 4,370 alloc'd
==311556== by 0x2B0DD2: ReadJPEGImage (jpeg.c:1653)
**

[Jaroslav Fojtik]

Please close this issue, I see nothing in valgrind

[Bob Friesenhahn]

I am seeing a huge number of reports from valgrind given the Mercurial updates available at this instant.

[Bob Friesenhahn]

In the out.txt file I am seeing an error message from GM that it does not support the JPEG format:

./gm convert: Unrecognized image format (JPEG:blob-0x70754e4x).

[Bob Friesenhahn]

This issue is fixed now.