Legacy ImageMagick Discussions Archive

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 find the presence of CURL in delegates disturbing. I'd like to ensure no files start remote connections as well.

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.

> if HTTPS is a coder it probably doesn't have anything to do with how you access the images

Its a convenience. You can say, for example,

• convert https://www.imagemagick.org/images/logo.jpg logo.png

> I find the presence of CURL in delegates disturbing.

Then remove it from your delegates.xml configuration file. As a consequence, you will no longer be able to access images from the web with HTTPS.

> I too would really like some information regarding these changes.

ImageMagick supports over 100 formats. Fours of these were found to have weaknesses. They typically are not used often, so simply deny your users the rights to use them by setting their rights to "none". See https://www.imagemagick.org/discourse-s ... =4&t=26801.

Reminder, we have patched the reported exploits in ImageMagick 7.0.1-1 and ImageMagick 6.9.3-10 available sometime tomorrow. You'll still need to add

• <policy domain="path" rights="none" pattern="@*" />

to your policy.xml configuration file to stop any indirect reads (e.g. @somefile).

Hi, is
<policy domain="path" rights="none" pattern="@*" />
necessary if I applied these already?
<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="URL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />

This site https://imagetragick.com/ recommends verifying magic bytes, is that mandatory to mitigate the vulnerability or are the policies above enough?

Thank you.

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.

Thanks for this write-up and the incoming fix.

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.

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.

> Does this configuration file also apply to imagick

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.

https://github.com/ImageMagick/ImageMag ... 8888cddc93 (delegates.xml.in)
https://github.com/ImageMagick/ImageMag ... a17eb5d181 (property.c)

https://github.com/ImageMagick/ImageMag ... ba2b218fcf (delegates.xml.in)
https://github.com/ImageMagick/ImageMag ... 4502c7e08b (property.c)

What does the following policy do?:
<policy domain="coder" rights="none" pattern="TEXT" />

Will this policy:
<policy domain="path" rights="none" pattern="@*" />
Allow for URLs and HTTPS? I use a lot of `convert https://www.example.com/logo.jpg logo.png` and `convert http://www.example.com/logo.jpg logo.png`

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.

Does ImageMagick Vulnerability occur in Portable Windows version?

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 "

..../LoadDelegateCache/1497/Configure
Loading delegate configuration file "built-in" ...
convert.exe: UnableToOpenConfigureFile `delegates.xml' @ warning/configure.c/Get
ConfigureOptions/706.

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.

Am I correct?

What versions are affected by this? I have some legacy machines running 6.2.8 that don't understand "convert -list policy". Is it safe to assume they aren't vulnerable?

frEEk:

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.

What platform? If unix, then try
on my Mac, I get

/usr/local/etc/ImageMagick-6/policy.xml
/usr/local/share/doc/ImageMagick-6/www/source/policy.xml

I would suspect that your systems are affected and need to have the new policies added to the policy.xml file, if you need to restrict the use of MVG, MSL or https: files.

I see my question is effectively the same as viewtopic.php?f=2&t=29614