Questions and postings pertaining to the development of ImageMagick, feature enhancements, and ImageMagick internals. ImageMagick source code and algorithms are discussed here. Usage questions which are too arcane for the normal user list should also be posted here.

Can you explain a little more about what these policies will do? For example, we currently access all of our imagemagick processes through HTTPS calls; would including HTTPS in our policy file like this cause issues with that? (Sorry for my ignorance!)

Edit: On second thought, if HTTPS is a coder it probably doesn't have anything to do with how you access the images. Right? But, I have never heard of an HTTPS image format, which is what confuses me with this one. Clarification would be nice.

caliguian wrote:Can you explain a little more about what these policies will do? For example, we currently access all of our imagemagick processes through HTTPS calls; would including HTTPS in our policy file like this cause issues with that? (Sorry for my ignorance!)

Edit: On second thought, if HTTPS is a coder it probably doesn't have anything to do with how you access the images. Right? But, I have never heard of an HTTPS image format, which is what confuses me with this one. Clarification would be nice.

I too would really like some information regarding these changes. I can't go implementing changes I don't understand into a production environment. I've tried finding documentation which specifies what these directives do and so far I can't find anything.

The indirect reads were coming from the MVG and MSL coders, so denying the right to use these coders should be sufficient to prevent exploits. Denying indirect reads with a path policy and a pattern of "@*" is supported in ImageMagick 6.9.3-10 and ImageMagick 7.0.1-1 for those that need to utilize the MVG and MSL coders.

Does this configuration file also apply to imagick (php5-imagick)? I am able to verify the policy takes effect using convert(1) on the command-line, but don't see any difference in phpinfo(), nor is there any "policy" section listed there.

imagick is a PHP wrapper for ImageMagick. We did not write nor do we support imagick. However, since it is a wrapper, we're confident the suggested changes to the policy.xml configuration file will prevent the specific exploits that apply to ImageMagick.

> A link to the patches for 7.0.1-1 and 6.9.3-10 would be appreciated so that we can backport this ASAP.

The URL policy simply denies access to non-https URLs. The @ policy denies access to indirect reads such as label:@mylabel.txt. If you need to use URLs in your workflow and remote users cannot access your scripts, you are likely safe to use URLs. If remote users use your ImageMagick scripts and you do not sanitize the input filenames or the files themselves, upgrade to ImageMagick 6.9.3-10 or 7.0.1-1. These versions have patches to prevent the reported vulnerabilities.

I'm using a Portable Windows Version 6.9.1.8 (only one convert.exe file), it seems to be this version has not been affected by Vulnerabilities
CVE-2016-3714
CVE-2016-3715
CVE-2016-3718
CVE-2016-3716

When I tried to convert exploit file as https://imagetragick.com/ described, I got an error delegate.xml was not found. Even it showed loading built-in delegate file but at the end, it still showed "UnableToOpenConfigureFile "

And no listing directory occurred (I changed command line from "ls" to "dir"). I'm feeling that portable version (or Windows version) has a bug with reading configuration files and fortunately it has not been affected by Vulnerabilities.

In general, please do not tack a new topic specific to your usage onto posts about a different topic. Please in the future start a new topic, specific to your problem. It will help the IM developers to find and answer your specific issue.