ImageTragick - ImageMagick Filtering Vulnerability - CVE-2016-3714

Public Date: May 3, 2016, 12:00 am
Updated -
Resolved Status
Important Impact

A vulnerability was found in Imagemagick where insufficient filtering for filenames passed to a delegate's command allows remote code execution during the conversion of several file formats.

Background Information

Imagemagick allows the processing of files with external libraries. This feature is called "delegate". It is implemented as a system() call with a command string ('command') from the config file delegates.xml with actual values for different parameters (input/output/filename, etc.). Because the %M parameter is insufficiently filtered, it is possible to inject shell commands. One of the default delegate commands uses the following to handle HTTPS requests:

"wget" -q -O "%o" "https:%M"

where %M is the actual link from the input. If wget or curl are installed, it is possible to pass the value "" |ls "-la" and unexpectedly execute 'ls -la'.

Take Action

All Red Hat customers using ImageMagick are strongly recommended to apply mitigations to their systems pending released security Errata. Recommended mitigations are found under the Resolve tab.

Impacted Products

Red Hat Product Security has rated this issue as having a security impact of Important.

The following Red Hat Product versions are impacted:

  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat OpenShift Enterprise


Any customer using ImageMagick to process untrusted or third-party images is potentally impacted. Examples include auto-generated thumbnail code using ImageMagick or third party usage of ImageMagick to process images uploaded to your servers, which is often done using web applications that receive untrusted user input.


Red Hat Enterprise Linux 6 & 7

As a workaround, the /etc/ImageMagick/policy.xml file can be edited to disable processing of MVG, HTTPS, HTTP, URL, FTP, EPHEMERAL, MSL, LABEL and TEXT commands within image files. In the <policymap> section, add the following lines:

<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="HTTP" />
<policy domain="coder" rights="none" pattern="URL" />
<policy domain="coder" rights="none" pattern="FTP" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />
<policy domain="coder" rights="none" pattern="TEXT" />
<policy domain="coder" rights="none" pattern="LABEL" />
<policy domain="path" rights="none" pattern="@*" />

Red Hat Enterprise Linux 5

In the following folders:

/usr/lib64/ImageMagick-6.2.8/modules-Q16/coders/ (64bit package)
/usr/lib/ImageMagick-6.2.8/modules-Q16/coders/ (32bit package)

Rename the following files,,, Example:

$ mv
$ mv
$ mv

Additional Mitigation

Additionally, customers can modify third-party code using ImageMagick to verify the image's validity before passing it to ImageMagick to process.

Updates for Affected Products

Product Package Advisory/Update
Red Hat Enterprise Linux 5 ImageMagick Will Not Fix
Red Hat Enterprise Linux 6 ImageMagick RHSA-2016-0726
Red Hat Enterprise Linux 7 ImageMagick RHSA-2016-0726


Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

/etc/ImageMagick DOES exist on RHEL7 if ImageMagick is installed. Updating the policy.xml there DOES change policy as seen with "convert -list policy"

/etc/IMageMagick does NOT exist on RHEL5 or RHEL6.

On RHEL6 policy.xml DOES exist but is in /usr/lib/ImageMagick/config (x386) and/or /usr/lib64/ImageMagick/config (x86_64). Updating the file there DOES change the policy.

On RHEL5 policy.xml is NOT installed by the version of ImageMagick used. Adding it manually to /usr/lib/ImageMagick or /usr/lib64/ImageMagick does NOT change the policy. In fact convert -list policy gives error:

convert: unrecognized list type `policy'.

I don't know if RHEL5's ImageMagick is in fact vulnerable as stated here but if so the fix is NOT just adding policy.xml as stated. Any ideas?

I think for RHEL 6 the location of policy.xml depends on the version of the package:

$ rpm -q ImageMagick
$ rpm -ql ImageMagick | grep policy.xml
$ rpm -q ImageMagick
$ rpm -ql ImageMagick | grep policy.xml

Good point. I didn't realize they had changed upstream version in RHEL6. Usually RedHat keeps the same upstream version of things and backports into it for their extended versioning. i.e. My expectation would have been that the next version on RHEL6 would still be a 6.5.4 upstream. The 6.7.2 does install /etc/ImageMagick: rpm -qlp ImageMagick- /etc/ImageMagick /etc/ImageMagick/coder.xml /etc/ImageMagick/colors.xml /etc/ImageMagick/delegates.xml /etc/ImageMagick/log.xml /etc/ImageMagick/magic.xml /etc/ImageMagick/mime.xml /etc/ImageMagick/policy.xml /etc/ImageMagick/sRGB.icm /etc/ImageMagick/thresholds.xml /etc/ImageMagick/type-dejavu.xml /etc/ImageMagick/type-ghostscript.xml /etc/ImageMagick/type-windows.xml /etc/ImageMagick/type.xml

OK RHEL5 is vulnerable.

At one of the reponses says:

"Karim Valiev posted information to the oss-security mailing list, showing how to check the local install of ImageMagick to see if it is vulnerable. (That includes link that I couldn't open:

Create a file called exploit.mvg with the following contents:

push graphic-context
viewbox 0 0 640 480
fill 'url("|ls "-la)'
pop graphic-context

Then run the convert utility:

$ convert exploit.mvg out.png

If you see a local directory listing, your installation of ImageMagick is not sufficiently protected."

On doing that on RHEL7 and RHEL6 before updating policy.xml it DID do the ls -l. After updating policy.xml it did NOT do the ls -l so the update fixed the issue.

On doing that on RHEL5 it DID do the ls -l which means RHEL5 does have the issue. However, as noted before policy.xml appears not to be supported in the RHEL5 version of ImageMagick so it isn't clear how to fix this on RHEL5.

The problem(s) can be mitigated on RHEL5 by editing delegates.xml (for the https delegate) and removing/disabling the relevant "coder" libraries, see the details posted here:

The links above to the Red Hat security advisories are not working at this point. I'm not sure if it is an error in the link or if the content is truly not there yet. I also haven't seen it come to our satellite server just yet even though we have ran several sync processes. Any idea when this will be released to the CDN for consumption?

Hello Guys,

Lately i received some Vulnerability for ImageMagick on my RHEL6 and 7 hosts from our Security team, While checking i found the below version of ImageMagick is installed however, at the same time we have newer version available IE "".

Current one:

rpm -qa | grep -i imagemagic

ImageMagick- ImageMagick-perl-

My question is now, if we just do "yum update ImageMagick" that will potentially lead to install "" which is newer version and will mitigate it but does it impact any application as such considering the below config file:

```cat /etc/ImageMagick/policy.xml <?xml version="1.0" encoding="UTF-8"?> ]> <!-- Configure ImageMagick policies.

Domains include system, 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"/>

Note, resource policies are maximums for each instance of ImageMagick (e.g. policy memory limit 1GB, -limit 2GB exceeds policy maximum so memory limit is 1GB). --> ```