Package: imagemagick / 8:6.7.7.10-5+deb7u3
Metadata
| Package | Version | Patches format |
|---|---|---|
| imagemagick | 8:6.7.7.10-5+deb7u3 | 3.0 (quilt) |
Patch series
view the series file| Patch | File delta | Description |
|---|---|---|
| 0001 Fix CVE 2012 3437 ImageMagick Magick_png_malloc size.patch | (download) |
coders/png.c |
30 25 + 5 - 0 ! |
[patch] fix cve-2012-3437 imagemagick: magick_png_malloc() size
argument
Tom Lane (tgl@redhat.com) 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 (Magick_png_malloc)
in turn calls AcquireMagickMemory with an improper size argument:
static png_voidp Magick_png_malloc(png_structp png_ptr,png_uint_32 size)
{
(void) png_ptr;
return((png_voidp) AcquireMagickMemory((size_t) size));
}
This is incorrect, the size argument should be declared png_alloc_size_t
according to 1.5, or png_size_t 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.
|
| 0002 Fix security bug 685903 libmagick 5 Fails an asserti.patch | (download) |
magick/attribute.c |
2 1 + 1 - 0 ! |
[patch] fix security bug #685903: libmagick++5 fails an assertion due to OpenMP related problem (1/3) On some PNG images, ImageMagick fails with an assertion in the read method. This happens because ImageMagick does not determine the maximum number of threads in a uniform way. This broke a django web application, so this problem could be used to conduct a DoS attack in some environments. In order to solve this problem we must apply three patches. git-svn-id https://www.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6@8761 aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 |
| 0003 Fix security bug 685903 libmagick 5 Fails an asserti.patch | (download) |
magick/attribute.c |
2 1 + 1 - 0 ! |
[patch] fix security bug #685903: libmagick++5 fails an assertion due to OpenMP related problem (2/3) On some PNG images, ImageMagick fails with an assertion in the read method. This happens because ImageMagick does not determine the maximum number of threads in a uniform way. This broke a django web application, so this problem could be used to conduct a DoS attack in some environments. In order to solve this problem we must apply three patches. git-svn-id: https://www.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6@8764 aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 |
| 0004 Fix security bug 685903 libmagick 5 Fails an asserti.patch | (download) |
magick/random-private.h |
4 2 + 2 - 0 ! |
[patch] fix security bug #685903: libmagick++5 fails an assertion due to OpenMP related problem (3/3) On some PNG images, ImageMagick fails with an assertion in the read method. This happens because ImageMagick does not determine the maximum number of threads in a uniform way. This broke a django web application, so this problem could be used to conduct a DoS attack in some environments. In order to solve this problem we must apply three patches. git-svn-id https://www.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6@8766 aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 |
| 0005 Memory leak after setjmp used variable need to be vo.patch | (download) |
coders/jpeg.c |
16 8 + 8 - 0 ! |
[patch] memory leak: after setjmp used variable need to be volatile According to POSIX setjmp manpage: All accessible objects have values as of the time longjmp() was called, except that the values of objects of automatic storage duration which are local to the function containing the invocation of the corresponding setjmp() which do not have volatile-qualified type and which are changed between the setjmp() invocation and longjmp() call are indeterminate. Previous code was not safe according to this specification and could lead to memory leak. If the setjmp handler is called after reading a corrupted png, ping_pixels may be null and thus lead to a memory leak. Mark this kind of variable as volatile. git-svn-id: https://www.imagemagick.org/subversion/ImageMagick/trunk@9558 aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 Cherry picked rom svn revision 9558 |
| 0006 Fix a memory leak in webp handling.patch | (download) |
coders/webp.c |
1 1 + 0 - 0 ! |
[patch] fix a memory leak in webp handling Under current code in WriteWEBPImage() they are a lacking WebPPictureFree(&picture) thus leading to a memory leak. Bug: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=21943 |
| 0007 Magick fix a memory leak.patch | (download) |
Magick++/lib/Image.cpp |
9 6 + 3 - 0 ! |
[patch] magick++ fix a memory leak Original code leak memory in case of corrupted image. When image->exception is thrown, the following DestroyExceptionInfo will not be executed, thus lead to a leak. Fix it by adding (void) DestroyExceptionInfo( &exceptionInfo ) before throwing. |
| 0008 Fix a buffer overflow.patch | (download) |
coders/gif.c |
8 1 + 7 - 0 ! |
[patch] fix a buffer overflow The gif handling code of imagemagick allow execution of arbitrary code due to a buffer overflow of one byte. |
| 0009 Fixing a buffer overflow in psd file handling.patch | (download) |
coders/psd.c |
12 6 + 6 - 0 ! |
[patch] fixing a buffer overflow in psd file handling MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A buffer overflow flaw affecting ImageMagick versions prior to 6.8.8-5 when handling PSD images was reported. CVE-2014-1947 (not affected) is a vulnerability in older ImageMagick versions (such as 6.5.4) that use the "L%02ld" string. The root cause here is that the code did not cover the case of more than 99 layers, which is apparently allowable but relatively uncommon. This has a resultant buffer overflow, e.g, L99\0 is safe but L100\0 is unsafe. When the overflow occurs, it can be described as "1 or more bytes too many." We are not affected by this bug, because we patch 6.7.7 version We are affected by CVE-2014-2030 assigned for the vulnerability in newer ImageMagick versions that use the "L%06ld" string. The root cause here is that the code did not recognize the relationship between the 8 (or more) characters in "L%06ld" and the actual buffer size. This has a resultant buffer overflow of "4 or more bytes too many." Bug-debian: http://bugs.debian.org/740250 Bug-redhat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-2030 git-svn-id: https://www.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6@13736 aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 |
| 0010 Added boundary checks in DecodePSDPixels.patch | (download) |
coders/psd.c |
6 5 + 1 - 0 ! |
[patch] added boundary checks in decodepsdpixels MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A buffer overflow flaw was found in the way ImageMagick handled PSD images that use RLE encoding. An attacker could create a malicious PSD image file that, when opened in ImageMagick, would cause ImageMagick to crash or, potentially, execute arbitrary code with the privileges of the user running ImageMagick. This patch fix CVE-2014-1958 Bug-redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1067276 Bug-debian: http://bugs.debian.org/740250 git-svn-id: https://subversion.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6@14801 aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 Signed-off-by: Bastien ROUCARIS <roucaries.bastien@gmail.com> |
| 0011 Prevent buffer overflow in messaging system CVE 2014.patch | (download) |
magick/locale.c |
10 9 + 1 - 0 ! |
[patch] prevent buffer overflow in messaging system (cve: 2014-1947) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bug-redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1067276 Bug-debian: http://bugs.debian.org/740250 git-svn-id: https://subversion.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6@14900 aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 Signed-off-by: Bastien ROUCARIS <roucaries.bastien@gmail.com> |
