ImageMagick Vulnerabilities

[magick]

Concerning ImageMagick 6.7.6-2 and earlier:

• [CVE-2012-0259] JPEG EXIF tag crash.
• [CVE-2012-0260] Excessive memory use with JPEG restart markers.
• [CVE-2012-1798] Copying of invalid memory when reading TIFF EXIF IFD.

Thanks goes to Aleksis Kauppinen, Joonas Kuorilehto and Tuomas Parttimaa of the Codenomicon CROSS project for discovering the vulnerabilities and providing a test case file. And thanks to the Finnish Communications Regulatory Authority (CERT-FI) for alerting us to these vulnerabilities

These patches are included in the ImageMagick 6.7.6-3 release. For earlier releases, here are the patches to repair these vulnerabilities:

Code: Select all

--- ImageMagick-6.7.5-10/magick/property.c      2012-02-29 20:41:19.000000000 -0500
+++ ImageMagick-6.7.6-3/magick/property.c       2012-03-28 19:00:20.537642844 -0400
@@ -1309,6 +1309,8 @@
             buffer[MaxTextExtent],
             *value;
 
+          value=(char *) NULL;
+          *buffer='\0';
           switch (format)
           {
             case EXIF_FMT_BYTE:
--- ImageMagick-6.7.5-10/coders/jpeg.c  2012-03-02 12:37:45.000000000 -0500
+++ ImageMagick-6.7.6-3/coders/jpeg.c   2012-03-28 19:00:11.641806710 -0400
@@ -319,6 +320,8 @@
 
 static MagickBooleanType JPEGWarningHandler(j_common_ptr jpeg_info,int level)
 {
+#define JPEGExcessiveWarnings  1000
+
   char
     message[JMSG_LENGTH_MAX];
 
@@ -337,11 +340,12 @@
         Process warning message.
       */
       (jpeg_info->err->format_message)(jpeg_info,message);
+      if (jpeg_info->err->num_warnings++ > JPEGExcessiveWarnings)
+        JPEGErrorHandler(jpeg_info);
       if ((jpeg_info->err->num_warnings == 0) ||
           (jpeg_info->err->trace_level >= 3))
         ThrowBinaryException(CorruptImageWarning,(char *) message,
           image->filename);
-      jpeg_info->err->num_warnings++;
     }
   else
     if ((image->debug != MagickFalse) &&
--- ImageMagick-6.7.5-10/coders/tiff.c  2012-02-13 19:43:58.000000000 -0500
+++ ImageMagick-6.7.6-3/coders/tiff.c   2012-03-28 19:00:06.795895975 -0400
@@ -647,7 +647,7 @@
         ascii=(char *) NULL;
         if ((TIFFGetField(tiff,exif_info[i].tag,&ascii,&sans,&sans) != 0) &&
             (ascii != (char *) NULL) && (*ascii != '\0'))
-          (void) CopyMagickMemory(value,ascii,MaxTextExtent);
+          (void) CopyMagickString(value,ascii,MaxTextExtent);
         break;
       }
       case TIFF_SHORT:

[magick]

Concerning ImageMagick 6.7.6-3 and earlier:

• [CVE-2012-1610] Potential EXIF Integer Overflow

Thanks to the Red Hat Security Response team for discovering this security flaw and patch.

This patch is included in the ImageMagick 6.7.6-4 release. For earlier releases, here is the patches to repair the vulnerability:

Code: Select all

--- ImageMagick-6.5.4-7/magick/property.c.cve-2012-0259 2012-04-02 13:25:21.000000000 +0200
+++ ImageMagick-6.5.4-7/magick/property.c.cve-2012-0259 2012-04-03 10:39:44.000000000 +0200
@@ -1294,6 +1294,8 @@ static MagickBooleanType GetEXIFProperty
         break;
       components=(long) ((int) ReadPropertyLong(endian,q+4));
       number_bytes=(size_t) components*tag_bytes[format];
+      if (number_bytes < components)
+        break;  /* prevent overflow */
       if (number_bytes <= 4)
         p=q+8;
       else

-- ImageMagick-6.5.4-7/magick/profile.c.cve-2012-0259 2012-04-02 13:25:21.000000000 +0200
+++ ImageMagick-6.5.4-7/magick/profile.c.cve-2012-0259 2012-04-03 10:39:44.000000000 +0200
@@ -6727,8 +6727,10 @@
       format=(ssize_t) ReadProfileShort(endian,q+2);
       if ((format-1) >= EXIF_NUM_FORMATS)
         break;
-      components=(int) ReadProfileLong(endian,q+4);
+      components=(ssize_t) ((int) ReadProfileLong(endian,q+4));
       number_bytes=(size_t) components*format_bytes[format];
+      if (number_bytes < components)
+        break;  /* prevent overflow */
       if (number_bytes <= 4)
         p=q+8;
       else

[tama]

Concerning ImageMagick 6.7.6-3 and earlier:

• [CVE-2012-1610] Potential EXIF Integer Overflow

Thanks to the Red Hat Security Response team for discovering this security flaw and patch.

This patch is included in the ImageMagick 6.7.6-4 release. For earlier releases, here is the patches to repair the vulnerability:

Here is the code that I have:

Code: Select all

--- ImageMagick-6.5.4-7/magick/property.c.cve-2012-0259 2012-04-02 13:25:21.000000000 +0200
+++ ImageMagick-6.5.4-7/magick/property.c.cve-2012-0259 2012-04-03 10:39:44.000000000 +0200
@@ -1294,6 +1294,8 @@ static MagickBooleanType GetEXIFProperty
         break;
       components=(long) ((int) ReadPropertyLong(endian,q+4));
       number_bytes=(size_t) components*tag_bytes[format];
+      if (number_bytes < components)
+        break;  /* prevent overflow */
       if (number_bytes <= 4)
         p=q+8;
       else

-- ImageMagick-6.5.4-7/magick/profile.c.cve-2012-0259 2012-04-02 13:25:21.000000000 +0200
+++ ImageMagick-6.5.4-7/magick/profile.c.cve-2012-0259 2012-04-03 10:39:44.000000000 +0200
@@ -6727,8 +6727,10 @@
       format=(ssize_t) ReadProfileShort(endian,q+2);
       if ((format-1) >= EXIF_NUM_FORMATS)
         break;
-      components=(int) ReadProfileLong(endian,q+4);
+      components=(ssize_t) ((int) ReadProfileLong(endian,q+4));
       number_bytes=(size_t) components*format_bytes[format];
+      if (number_bytes < components)
+        break;  /* prevent overflow */
       if (number_bytes <= 4)
         p=q+8;
       else

Hi
What are the dangers of not implementing this patch?

[anthony]

It is only dangerous if the images ImageMagick processes come from some unknown source, such as a typical user on the web.
The above basically basically says they crash the system. When means some limit check or input verification failed, somewhere.

However if some 'cracker' does a lot of work (much of it guess work) and know the exact version of IM you are using, they 'may' be able to use that failure to get IM to execute some other, user provided code. Code that could for example run a program to open a command line into the web server computer IM is running on.

Note that is it unlikely someone would spend that much effort for access to just one computer. It would be 'pay'. Such effort is more likely in a more common system, such as a well know web server, wiki (Apache), forum application (like this one), OS (AKA microsoft windows), and so on. So if you app become popular, THEN you may have a problem.

It is always better however to know about a potential problem, such as what is being reported by these security teams, and have it fixed, than leave it. Program bugs like these are easy to lose, even by the program who has intimate knowledge of the code working, and thus what is causing the problem. In fact there is a 'logic' proof that basically says that it is impossible to prove a program is bug free. As such all that we can do is make any actual bug as rare as we can.

[glennrp]

Anthony: It's not that unlikely that a cyber warrior would be focused on a particular target.
Or that a "cracker" attempting to escalate his or her priviledges on a particular
machine.

Tama: If you are talking about your own computer, don't have any untrusted users on
it[1], and you aren't processing images from untrusted sources, then there is little danger,
but I'd try to fix any known vulnerabilities right away anyhow.

[1] You can't be sure you don't have untrusted users if your system is connected to
the net; they might have cracked your system and opened a back door!

[axxo1]

Does it cause segmentation faults as well?

I believe this is what is happening to me. Need to upgrade...

[amelia albert]

Is this patch still valuable or get obsoleted?
InfantigoPiercingHome Remedies