ImageMagick before 7.1.2-30 contains a time-of-check-time-of-use vulnerability in path policy enforcement on Windows that allows attackers to bypass read or write restrictions by exploiting symlink race conditions. Attackers can swap symlinks between policy validation and file access to read or write policy-denied files.
ImageMagick before 7.1.2-30 and 6.9.13-55 contains a time-of-check-time-of-use (TOCTOU) vulnerability in the video decoder that allows attackers to bypass path policy write restrictions via symlink swaps. An attacker can replace a symlink between policy validation (check-time) and the file write operation (use-time) to write to policy-denied locations.
ImageMagick before 7.1.2-26 (and 6.x before 6.9.13-51) contains a memory leak in the TIFF encoder that occurs when a temporary file cannot be created, resulting in a small memory leak.
ImageMagick before 7.1.2-26 contains a memory leak vulnerability in the JNG encoder when a blob cannot be opened. Attackers can trigger the memory leak by providing malformed JNG files that fail blob operations, causing resource exhaustion.
ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in the MIFF encoder that occurs when a memory allocation fails during MIFF image processing, which can lead to denial of service.
ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in color transformation to the log colorspace: when the operation fails, a small amount of memory is not released.
ImageMagick before 7.1.2-26 contains a memory leak vulnerability in the TIFF encoder when memory allocation fails. Attackers can trigger allocation failures during TIFF image processing to cause memory exhaustion and denial of service.
ImageMagick before 7.1.2-26 and 6.9.13-51 contains a heap-based buffer over-write vulnerability that occurs when running an X11 import with a crafted window title, which can result in heap memory corruption and denial of service.
ImageMagick before 7.1.2-26 and 6.9.13-51 contains an information disclosure vulnerability: when a profile is displayed with the identify command and the profile value is not printable, a single byte at the end of the profile can be printed (read past the profile boundary). This behavior occurs when debug output is enabled.
ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in the TIFF encoder when an invalid tiff:tile-geometry is specified. Supplying malformed tile geometry parameters causes allocated memory not to be released, which can lead to increased memory consumption.
ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in the hough lines operation: when a specific operation fails, a small memory leak occurs.
ImageMagick before 7.1.2-26 contains a memory leak vulnerability in the VIFF encoder when memory allocation fails. Attackers can trigger allocation failures by processing specially crafted VIFF images to exhaust available memory and cause denial of service.
ImageMagick before 7.1.2-15 contains a heap-buffer-overflow read vulnerability in GetPixelIndex caused by OpenPixelCache updating image channel metadata before pixel cache memory allocation. Attackers can trigger memory and disk allocation failures to cause a heap-buffer-overflow read affecting any writer calling GetPixelIndex.
ImageMagick before 7.1.2-13 contains a memory leak vulnerability in LoadOpenCLDeviceBenchmark() function when parsing malformed OpenCL device profile XML files with unclosed device elements. Attackers with write access to the OpenCL cache directory can place malicious XML files to exhaust memory and cause denial of service.
ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.1-14, ImageMagick crashes when processing a crafted TIFF file. Version 7.1.1-14 fixes the issue.
A Debian bug report [1] indicated that ImageMagick would load configuration files from the current working directory, rather than just standard directories like ~/.magick/ or /usr/lib/ImageMagick-/config/. If a user were to run certain ImageMagick programs, like the convert utility, from untrusted directories it could allow for the execution of arbitrary code as the user running the program.
Upstream has corrected [2] this flaw is noted as being fixed in the 6.6.5-5 ChangeLog [3].
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601824 [2] http://trac.imagemagick.org/changeset?new=3022%40ImageMagick%2Ftrunk%2Fmagick%2Fconfigure.c&old=2002%40ImageMagick%2Ftrunk%2Fmagick%2Fconfigure.c [3] http://trac.imagemagick.org/browser/ImageMagick/trunk/ChangeLog
Tom Lane (tgl) found an issue in ImageMagick. Basically CVE-2011-3026 deals with libpng memory allocation, limitations have been added so that a bad PNG can't cause the system to allocate a lot of memory causing a denial of service. However on further investigation of ImageMagick Tom Lane found that PNG malloc function (Magickpngmalloc) in turn calls AcquireMagickMemory with an improper size argument:
#ifdef PNGUSERMEMSUPPORTED static pngvoidp Magickpngmalloc(pngstructp pngptr,pnguint32 size) { (void) pngptr; return((pngvoidp) AcquireMagickMemory((sizet) size)); }
This is incorrect, the size argument should be declared pngallocsizet according to 1.5, or pngsizet according to 1.2.
"As this function stands, it invisibly does the wrong thing for any request over 4GB. On big-endian architectures it very possibly will do the wrong thing even for requests less than that. So the reason why the hard-wired 4GB limit prevents a core dump is that it masks the ABI mismatch here."
So basically we have memory allocations problems that can probably lead to a denial of service.
Tom Lane (tgl) found an issue in ImageMagick that is also present in GraphicsMagick. Basically CVE-2011-3026 deals with libpng memory allocation, limitations have been added so that a bad PNG can't cause the system to allocate a lot of memory causing a denial of service. However on further investigation of ImageMagick Tom Lane found that PNG malloc function (Magickpngmalloc) in turn calls AcquireMagickMemory with an improper size argument:
#ifdef PNGUSERMEMSUPPORTED static pngvoidp Magickpngmalloc(pngstructp pngptr,pnguint32 size) { (void) pngptr; return((pngvoidp) AcquireMagickMemory((sizet) size)); }
Similar code is present in GraphicsMagick:
#ifdef PNGUSERMEMSUPPORTED static pngvoidp pngIMmalloc(pngstructp pngptr,pnguint32 size) { (void) pngptr; return MagickAllocateMemory(pngvoidp,(sizet) size); }
This is incorrect, the size argument should be declared pngallocsizet according to 1.5, or pngsizet according to 1.2.
"As this function stands, it invisibly does the wrong thing for any request over 4GB. On big-endian architectures it very possibly will do the wrong thing even for requests less than that. So the reason why the hard-wired 4GB limit prevents a core dump is that it masks the ABI mismatch here."
So basically we have memory allocations problems that can probably lead to a denial of service.