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 !
1 file changed, 25 insertions(+), 5 deletions(-)

 [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 !
magick/cache-view.c | 2 1 + 1 - 0 !
magick/cache.c | 2 1 + 1 - 0 !
magick/draw.c | 2 1 + 1 - 0 !
magick/fx.c | 2 1 + 1 - 0 !
magick/image-view.c | 6 3 + 3 - 0 !
magick/paint.c | 2 1 + 1 - 0 !
magick/profile.c | 4 2 + 2 - 0 !
magick/quantize.c | 2 1 + 1 - 0 !
magick/quantum.c | 2 1 + 1 - 0 !
magick/resize.c | 2 1 + 1 - 0 !
magick/statistic.c | 4 2 + 2 - 0 !
12 files changed, 16 insertions(+), 16 deletions(-)

 [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 !
magick/cache-view.c | 2 1 + 1 - 0 !
magick/cache.c | 2 1 + 1 - 0 !
magick/draw.c | 2 1 + 1 - 0 !
magick/fx.c | 2 1 + 1 - 0 !
magick/image-view.c | 6 3 + 3 - 0 !
magick/paint.c | 2 1 + 1 - 0 !
magick/profile.c | 4 2 + 2 - 0 !
magick/quantize.c | 2 1 + 1 - 0 !
magick/quantum.c | 2 1 + 1 - 0 !
magick/resize.c | 2 1 + 1 - 0 !
magick/statistic.c | 4 2 + 2 - 0 !
12 files changed, 16 insertions(+), 16 deletions(-)

 [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 !
magick/resample-private.h | 4 2 + 2 - 0 !
2 files changed, 4 insertions(+), 4 deletions(-)

 [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 !
coders/png.c | 4 2 + 2 - 0 !
2 files changed, 10 insertions(+), 10 deletions(-)

 [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 !
1 file changed, 1 insertion(+)

 [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 !
1 file changed, 6 insertions(+), 3 deletions(-)

 [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 !
1 file changed, 1 insertion(+), 7 deletions(-)

 [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 !
1 file changed, 6 insertions(+), 6 deletions(-)

 [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 !
1 file changed, 5 insertions(+), 1 deletion(-)

 [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 !
1 file changed, 9 insertions(+), 1 deletion(-)

 [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>