Heap-based buffer overflow in the PushQuantumPixel function in ImageMagick before 6.9.7-3 and 7.x before 7.0.4-3 allows remote attackers to cause a denial of service (application crash) via a crafted TIFF file.
In ImageMagick before 6.9.8-8 and 7.x before 7.0.5-9, the ReadJP2Image function in coders/jp2.c does not properly validate the channel geometry, leading to a crash.
In ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1, a crafted PNG file could trigger a crash because there was an insufficient check for short files.
In ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1, the ReadOneMNGIm ...
In ImageMagick before 6.9.7-6 and 7.x before 7.0.4-6, the ReadMATImage ...
Last updated 24 July 2024
The WriteOnePNGImage function in coders/png.c in ImageMagick through 6.9.9-0 and 7.x through 7.0.6-1 allows remote attackers to cause a denial of service (NULL pointer dereference) via a crafted file.
A vulnerability of integer overflow and subsequent buffer overflow was found in coders/icon.c. Memory is allocated based on the sum of a user-supplied value and a fixed value. That sum can overflow, causing only a small amount of memory to be allocated, while the program assumes more was allocated.
Vulnerable code:
iconfile.directory[i].offset=ReadBlobLSBLong(image);
On this line, it reads in 4byte value from the image and stores it in iconfile.directory[i].size.
length=iconfile.directory[i].size; png=(unsigned char ) AcquireQuantumMemory(length+16,sizeof(png));
Here the value of length is set to the value stored in iconfile.directory[i].size. At following line, 16 is added to length and allocates that amount of png structures. However, if length+16 overflows (for example, length == 2^32 - 15), it will only allocate memory for a single png. This is a problem, because the following lines assume that at least 16 bytes was allocated:
(void) CopyMagickMemory(png,"\211PNG\r\n\032\n\000\000\000\015",12); png[12]=(unsigned char) iconinfo.planes; png[13]=(unsigned char) (iconinfo.planes >> 8); png[14]=(unsigned char) iconinfo.bitsperpixel; png[15]=(unsigned char) (iconinfo.bitsperpixel >> 8);
And then the following line has a call to ReadBlob, and since length-16 will underflow (and the length is treated as a sizet), it will effectively execute a strcpy with the remaining data in the image file.
count=ReadBlob(image,length-16,png+16);
Detailed stacktrace with reproducer can be found here:
https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1459747
Upstream patch (only the "coders/icon.c" subsection of the commit is relevant):
https://github.com/ImageMagick/ImageMagick/commit/0f6fc2d5bf8f500820c3dbcf0d23ee14f2d9f734
CVE request:
http://seclists.org/oss-sec/2015/q4/45
A double free flaw was found in ImageMagick in pict.c.
Detailed stacktrace with reproducer can be found here: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1490362
Upstream patch to the vulnerability in tga.c can be found here:
https://github.com/ImageMagick/ImageMagick/commit/4f68e9661518463fca523c9726bb5d940a2aa6d8
In ImageMagick before 6.9.9-3 and 7.x before 7.0.6-3, there is a missing NULL check in the ReadMATImage function in coders/mat.c, leading to a denial of service (assertion failure and application exit) in the DestroyImageInfo function in MagickCore/image.c.
In ImageMagick before 6.9.8-5 and 7.x before 7.0.5-6, there is a memory leak in the ReadMATImage function in coders/mat.c.
In ImageMagick before 6.9.9-1 and 7.x before 7.0.6-2, the ReadOnePNGImage function in coders/png.c allows remote attackers to cause a denial of service (application hang in LockSemaphoreInfo) via a PNG file with a width equal to MAGICKWIDTHLIMIT.
In ImageMagick before 6.9.9-4 and 7.x before 7.0.6-4, a crafted file could trigger a memory leak in ReadOnePNGImage in coders/png.c.
The ProcessMSLScript function in coders/msl.c in ImageMagick before 6.9.9-5 and 7.x before 7.0.6-5 allows remote attackers to cause a denial of service (memory leak) via a crafted file, related to the WriteMSLImage function.
The ReadMATImage function in coders/mat.c in ImageMagick through 6.9.9-3 and 7.x through 7.0.6-3 has memory leaks involving the quantuminfo and cloneinfo data structures.
The WriteBlob function in MagickCore/blob.c in ImageMagick before 6.9.8-10 and 7.x before 7.6.0-0 allows remote attackers to cause a denial of service (assertion failure and application exit) via a crafted file.
The ReadDIBImage function in coders/dib.c in ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1 allows remote attackers to cause a denial of service (memory leak) via a crafted file.
The ReadTXTImage function in coders/txt.c in ImageMagick through 6.9.9 ...
The ReadEPTImage function in coders/ept.c in ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1 allows remote attackers to cause a denial of service (memory consumption) via a crafted file.
The ReadOneMNGImage function in coders/png.c in ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1 allows remote attackers to cause a denial of service (large loop and CPU consumption) via a crafted file.
The ReadDPXImage function in coders/dpx.c in ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1 allows remote attackers to cause a denial of service (memory consumption) via a crafted file.
The ReadCINImage function in coders/cin.c in ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1 allows remote attackers to cause a denial of service (memory consumption) via a crafted file.
The ReadMATImage function in coders/mat.c in ImageMagick before 6.9.9-0 and 7.x before 7.0.6-1 allows remote attackers to cause a denial of service (memory leak) via a crafted file.
The ReadOneJNGImage function in coders/png.c in ImageMagick through 6.9.9-0 and 7.x through 7.0.6-1 allows remote attackers to cause a denial of service (large loop and CPU consumption) via a malformed JNG file.