CVE-2008-3134 and imagemagick

[broucaries]

Hi,

The debian security team is reporting us the CVE-2008-3134 for graphickmagick. Does it is a thread for imagemagick (version 6.2.4.5, 6.3.7.9, and last version)

If not could be possible to get security patch for these version ?

the graphicksmagick patch are availble on https://bugzilla.redhat.com/show_bug.cg ... -2008-3134

Regards

Bastien

[magick]

We had reviewed CVE-2008-3134 when it was first released and determined that the ImageMagick releases at that time did not suffer from the vulnerabilities. Its possible that older versions of ImageMagick (circa 2002) might have the vulnerabilities. DOS vulnerabilities are addressed with the -limit option. Its perfectly valid, for example, to convert a 200000x200000 pixel image but it may be disruptive to a multi-user system. A solution may be to set the disk limit to say 1GB so that any image that exceeds the limit causes ImageMagick to exit. You can set a system wide policy in recent releases of ImageMagick. Just edit policy.xml:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policymap [
<!ELEMENT policymap (policy)+>
<!ELEMENT policy (#PCDATA)>
<!ATTLIST policy domain (delegate|coder|filter|path|resource) #IMPLIED>
<!ATTLIST policy name CDATA #IMPLIED>
<!ATTLIST policy rights CDATA #IMPLIED>
<!ATTLIST policy pattern CDATA #IMPLIED>
<!ATTLIST policy value CDATA #IMPLIED>
]>
<!--
  Configure ImageMagick policies.

  Domains include delegate, coder, filter, path, or resource.

  Rights include none, read, write, and execute.  Use | to combine them,
  for example: "read | write" to permit read from, or write to, a path.

  Use a glob expression as a pattern.

  Suppose we do not want users to process MPEG video images:

    <policy domain="delegate" rights="none" pattern="mpeg:decode" />

  Here we do not want users reading images from HTTP:

    <policy domain="coder" rights="none" pattern="HTTP" />

  Lets prevent users from executing any image filters:

    <policy domain="filter" rights="none" pattern="*" />

  The /repository file system is restricted to read only. We use a glob
  expression to match all paths that start with /repository:
  
    <policy domain="path" rights="read" pattern="/repository/*" />

  Any large image is cached to disk rather than memory:

    <policy domain="resource" name="area" value="1gb"/>
-->
<policymap>
  <!-- <policy domain="resource" name="temporary-path" value="/tmp"/> -->
  <!-- <policy domain="resource" name="memory" value="2gb"/> -->
  <!-- <policy domain="resource" name="map" value="4gb"/> -->
  <!-- <policy domain="resource" name="area" value="1gb"/> -->
  <!-- <policy domain="resource" name="disk" value="16eb"/> -->
  <!-- <policy domain="resource" name="file" value="768"/> -->
  <!-- <policy domain="resource" name="thread" value="8"/> -->
  <!-- <policy domain="resource" name="time" value="3600"/> -->
</policymap>

[broucaries]

One of our user told us:
>i don't think that this has been addressed yet. if you compare the
> redhat patch [0] to the unstable imagemagick source, you
> will see that the additional limits to prevent these dos' are not
> included. for example, looking at coders/avs.c you can see that the new
> image size limits (AVS_WIDTH_LIMIT and AVS_HEIGHT_LIMIT) are not
> applied. the same can probably be found for the other affected files,
> but i have not checked.
>
> mike
>
> [0] https://bugzilla.redhat.com/attachment.cgi?id=311575

Thank you

Bastien

[magick]

The AVS image format supports image widths and heights up to 4294967295 x 4294967295 pixels. We will place limits on the width and height if someone points us to a published AVS image specification that shows that the width or height is limited to something less than 4294967295 pixels.

We created a 131071x131071 AVS image and ImageMagick did the right thing, it threw an exception that there were not enough resources rather than fault. On a system that had plenty of resources, the conversion finished without complaint.

As mentioned previously, DOS attacks are remediated with ImageMagick limits. You can set them from the policy (edit policy.xml), the environment (e.g. MAGICK_LIMIT_AREA), or from the command line (e.g. -limit area). It does not make sense for ImageMagick to artificially limit the image width and height because what may be a DOS on your system may be fine on ours (we have a 20 processor system with 72 terabytes of disk). Note, for DOS limits you'll want to set the area and disk limits. The area limits force images greater than the limit from memory to disk and the disk limit causes ImageMagick to exit if that limit is exceeded. For example, an area limit of 16mb forces any image greater than 4096x4096 pixels from memory to disk and with a disk limit of 1GB, any huge image will cause ImageMagick to exit with an exception. These limits in concert prevent denial-of-service attacks.

We are interested in any images that causes ImageMagick to fault. Post a URL to the image here and a description of the problem. If we can reproduce the fault, we will generate a patch within a day or two.