stack-buffer-overflow in WriteWEBPImage
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
#536 stack-buffer-overflow in WriteWEBPImage
GraphicsMagick 1.4 snapshot-20171217 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2017 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 yes
JPEG-2000 yes
JPEG yes
Little CMS yes
Loadable Modules no
OpenMP yes (201511)
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:
./configure 'CC=gcc' 'CXX=g++' 'CFLAGS=-g -fsanitize=address'
Final Build Parameters:
CC = gcc
CFLAGS = -fopenmp -g -fsanitize=address -Wall -pthread
CPPFLAGS = -I/usr/include/freetype2 -I/usr/include/libxml2
CXX = g++
CXXFLAGS = -pthread
LDFLAGS =
LIBS = -ljbig -lwebp -lwebpmux -llcms2 -ltiff -lfreetype -ljasper -ljpeg -lpng16 -lwmflite -lXext -lSM -lICE -lX11 -llzma -lbz2 -lxml2 -lz -lm -lgomp -lpthread
gm convert stack-buffer-overflow-23c880a9773dfe93ff.tif.webp /dev/null
==4237==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcd6e6d230 at pc 0x0000009005dd bp 0x7ffcd6e6a780 sp 0x7ffcd6e6a770
READ of size 8 at 0x7ffcd6e6d230 thread T0
#0 0x9005dc in ProgressCallback coders/webp.c:486
#1 0x7f1ead083973 (/lib64/libwebp.so.7+0x4f973)
#2 0x7f1ead067487 (/lib64/libwebp.so.7+0x33487)
#3 0x7f1ead085b66 (/lib64/libwebp.so.7+0x51b66)
#4 0x7f1ead067d7b (/lib64/libwebp.so.7+0x33d7b)
#5 0x7f1ead083e36 in WebPEncode (/lib64/libwebp.so.7+0x4fe36)
#6 0x902a79 in WriteWEBPImage coders/webp.c:716
#7 0x48af04 in WriteImage magick/constitute.c:2230
#8 0x48b8d7 in WriteImages magick/constitute.c:2387
#9 0x4309e8 in ConvertImageCommand magick/command.c:6087
#10 0x43c909 in MagickCommand magick/command.c:8872
#11 0x469409 in GMCommandSingle magick/command.c:17393
#12 0x4696f0 in GMCommand magick/command.c:17446
#13 0x40d0e6 in main utilities/gm.c:61
#14 0x7f1ea9efe039 in __libc_start_main (/lib64/libc.so.6+0x21039)
#15 0x40d019 in _start (/usr/local/bin/gm+0x40d019)
Address 0x7ffcd6e6d230 is located in stack of thread T0 at offset 256 in frame
#0 0x900667 in WriteWEBPImage coders/webp.c:493
This frame has 8 object(s):
[32, 48) 'encoded_image'
[96, 112) 'chunk'
[160, 176) 'picture_profiles'
[224, 256) 'writer' <== Memory access at offset 256 overflows this variable
[288, 342) 'data_features'
[384, 500) 'configure'
[544, 732) 'statistics'
[768, 1024) 'picture'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow coders/webp.c:486 in ProgressCallback
testcase: https://github.com/henices/pocs/raw/master/stack-buffer-overflow-23c880a9773dfe93ff.tif.webp.zip
I am encountering difficulties with reproducing this problem. Exactly what version of libwebp is being used? What does 'gm convert -list formats |grep WEBP' report?
I found the cause of the problem. The contribution of support for EXIF and ICC profiles has caused a different structure type to be passed into the progress callback. This means that the progress callback can not work with newer libwebp until a solution is found.
This problem is fixed by Mercurial changeset 15311:6dda3c33f35f. The problem is specific to libwebp 0.5.0 or later.
Credit: zz of NSFocus Security Team