Corrupt input may lead to crash

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
User avatar
mi
Posts: 123
Joined: 2005-01-25T14:14:43-07:00
Contact:

Corrupt input may lead to crash

Post by mi » 2017-04-13T16:27:27-07:00

I tried to identify an image, while it was still being saved by scanimage. Instead of either successfully identifying or outputting an error-message, the utility crashed. Using ImageMagick 6.9.6-4 Q16 amd64 2017-03-15 on FreeBSD. According to gdb, the stack is:

Code: Select all

Core was generated by `identify corrupt.png'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000000803d74b7a in thr_kill () from /lib/libc.so.7
(gdb) where
#0  0x0000000803d74b7a in thr_kill () from /lib/libc.so.7
#1  0x0000000803d74ab6 in raise () from /lib/libc.so.7
#2  0x0000000803d73259 in abort () from /lib/libc.so.7
#3  0x0000000800b1d789 in ?? () from /opt/lib/libMagickCore-6.so.2
#4  0x0000000803a25a3b in ?? () from /lib/libthr.so.3
#5  0x0000000803a2511c in ?? () from /lib/libthr.so.3
#6  <signal handler called>
#7  0x0000000803d74b7a in thr_kill () from /lib/libc.so.7
#8  0x0000000803d74ab6 in raise () from /lib/libc.so.7
#9  0x0000000803d73259 in abort () from /lib/libc.so.7
#10 0x0000000800b1d789 in ?? () from /opt/lib/libMagickCore-6.so.2
#11 0x0000000803a25a3b in ?? () from /lib/libthr.so.3
#12 0x0000000803a2511c in ?? () from /lib/libthr.so.3
#13 <signal handler called>
#14 0x0000000807095228 in ?? () from /opt/lib/ImageMagick-6.9.6/modules-Q16HDRI/coders/pnm.so
#15 0x0000000800a83192 in ReadImage () from /opt/lib/libMagickCore-6.so.2
#16 0x0000000800b96ec0 in ReadStream () from /opt/lib/libMagickCore-6.so.2
#17 0x0000000800a82bee in PingImage () from /opt/lib/libMagickCore-6.so.2
#18 0x0000000800a82e28 in PingImages () from /opt/lib/libMagickCore-6.so.2
#19 0x0000000800f31054 in IdentifyImageCommand () from /opt/lib/libMagickWand-6.so.2
#20 0x0000000800f64f19 in MagickCommandGenesis () from /opt/lib/libMagickWand-6.so.2
#21 0x0000000000400c14 in ?? ()
#22 0x0000000000400adf in ?? ()
#23 0x0000000800622000 in ?? ()
#24 0x0000000000000000 in ?? ()
With the completed scan ImageMagick has no problems -- identifying, converting, and displaying the image properly. But if the library can crash like this from corrupted input, it can be used to DOS a server or, perhaps, even allow an attacker to break-in by carefully crafting the fake "image" file.

I see no way to attach a file on this site -- please, download the test file from my server.

Please, fix.
Last edited by mi on 2017-04-14T09:43:48-07:00, edited 1 time in total.

User avatar
magick
Site Admin
Posts: 11095
Joined: 2003-05-31T11:32:55-07:00

Re: Corrupt PNG leads to SIGABRT

Post by magick » 2017-04-13T17:29:59-07:00

Unfortunately we cannot reproduce the problem. We get expected results with ImageMagick 6.9.6-4 under CentOS 7 compiled with the gcc address sanitizer enabled:

Code: Select all

-> identify corrupt.png
identify: unable to read image data `corrupt.png' @ error/pnm.c/ReadPNMImage/942.

User avatar
glennrp
Posts: 1147
Joined: 2006-04-01T08:16:32-07:00
Location: Maryland 39.26.30N 76.16.01W

Re: Corrupt PNG leads to SIGABRT

Post by glennrp » 2017-04-14T07:35:50-07:00

The test file actually contains a corrupt PPM file with the .png extension.
studio> od -c corrupt.png | head
0000000 P 6 \n # S A N E d a t a f
0000020 o l l o w s \n 2 7 5 2 4 6 0 4
0000040 \n 2 5 5 \n 377 377 377 377 377 377 377 377 377 377 377
0000060 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377
*
"identify corrupt.ppm" also rejects the file if the extension is changed to .ppm

User avatar
mi
Posts: 123
Joined: 2005-01-25T14:14:43-07:00
Contact:

Re: Corrupt input may lead to crash

Post by mi » 2017-04-14T09:43:21-07:00

Unfortunately we cannot reproduce the problem. We get expected results with ImageMagick 6.9.6-4 under CentOS 7 compiled with the gcc address sanitizer enabled
Khmm... I doubt, this is OS-specific, but it may be compiler-specific -- FreeBSD uses clang by default ("cc" means clang-3.4.1 here, although later versions are available too). Also, -fstack-protector is among CFLAGS by default.

Could this be the reason for the observed differences in behavior?
The test file actually contains a corrupt PPM file with the .png extension.
Indeed! This must be, how scanimage works -- outputs the data in PPM and then converts into the format requested. Good to know. Also, the crash, according to gdb, is inside PNM-module, not PNG. But it still should not crash :)

Post Reply