1. Introduction
The ImageMagick convert command is a universal converter between formats. Still, because of its powerful codebase and the binary format it can handle, certain restrictions may apply when attempting to transform some files.
In this tutorial, we talk about the security policies of ImageMagick and how to circumvent them. First, we define what a security policy is. After that, we understand the security policy options of ImageMagick. Finally, we show an example of a convert restriction and how to lift it.
We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments unless otherwise specified.
2. Security Policy
A security policy (secpol) is a set of rules that govern the behavior of a system in terms of security:
- limits such as soft and hard resource usage limits
- restrictions such as firewall configuration
- authentication
- authorization
- logging
- auditing
For example, SELinux is a way to configure and enforce most of the above and other security measures globally in Linux systems.
Depending on the security policy mechanism, we can switch between different rulesets quickly and efficiently to comply with the current conditions.
3. ImageMagick Security Policy
Due to the ubiquity and large codebase of ImageMagick and its toolset, there is a wide attack surface a potential exploit might leverage:
In fact, many ImageMagick vulnerabilities have been found over the years in other areas as well. In other words, with a large feature set, i.e., great power, comes a bigger potential for security issues and, thus, greater responsibility.
So, ImageMagick enables administrators to configure a security policy in many domains:
- cache – memory security
- code – restrict format and pattern rights
- delegate – limit the use of delegates
- filter – restrict filter usage
- modules – enable or disable a whole module depending on filters
- paths – restrict
- resources – set resource usage limit
- system – internal configuration and defaults
Although the defaults are fairly open in most cases, we can check our current security policy within the XML file at /etc/ImageMagick-<VERSION>/policy.xml, where <VERSION> is the version of ImageMagick we use:
$ cat /etc/ImageMagick-*/policy.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policymap [
<!ELEMENT policymap (policy)*>
<!ATTLIST policymap xmlns CDATA #FIXED ''>
<!ELEMENT policy EMPTY>
[...]
Here, we use an * asterisk or wildcard to check the policy of any available ImageMagick version.
Let’s see an example security policy rule:
<policy domain="system" name="max-memory-request" value="256MiB"/>For instance, this line in policy.xml is a max-memory-request limitation in the system domain that restricts allocating more than 256 mebibytes for a given operation.
In summary, certain conversions and operations may result in an error if we attempt to overstep security policy rules.
4. Modify Default ImageMagick Security Policy
After understanding security policies and their ImageMagick implementation, let’s see how we can change the default policy.xml to lift some restrictions.
First, we attempt a restricted conversion. After that, we remove the limitation and retry.
4.1. Restricted Conversion
Let’s try to convert a PDF file into a PNG file:
$ convert -density 6 -quality 66 in.pdf out.png
convert-im6.q16: attempt to perform an operation not allowed
by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.
convert-im6.q16: no images defined `out.png' @ error/convert.c/ConvertImageCommand/3229.In this case, convert tells us that we tried to perform an operation [that is] not allowed. Consequently, we also don’t see the out*.png output files.
Let’s also attempt to convert from TXT to PDF:
$ convert TEXT:in.txt out.pdf
convert-im6.q16: attempt to perform an operation not allowed
by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.Again, the message directs us that the PDF security policy prevented the conversion during an IsCoderAuthorized check.
4.2. Remove Restriction
After gathering some data about the security policy rule that relates to our case, we can search for it in /etc/ImageMagick-<VERSION>/policy.xml:
$ grep PDF /etc/ImageMagick-*/policy.xml
<!-- <policy domain="module" rights="none" pattern="{PS,PDF,XPS}" /> -->
<policy domain="coder" rights="none" pattern="PDF" />Here, we use grep to check for PDF in any lines of policy.xml. Of the two lines found, one is commented out and, thus, disabled.
The second line is the culprit behind the earlier output:
<policy domain="coder" rights="none" pattern="PDF" />This policy in the coder domain removes any rights when it comes to conversions matching the PDF pattern. In other words, a PDF file can’t be the input or output of a conversion.
To lift the restriction, we can edit policy.xml and comment out or modifying the restricting lines:
$ grep PDF /etc/ImageMagick-*/policy.xml
<!-- <policy domain="module" rights="none" pattern="{PS,PDF,XPS}" /> -->
<!-- <policy domain="coder" rights="none" pattern="PDF" /> -->Now, both lines pertaining to PDF conversions are disabled. At this point, we should be able to perform all PDF conversions as usual.
5. Summary
In this article, we looked at security policies and how their implementation in ImageMagick works.
In conclusion, if conversions are disallowed or limited, we can alter the security policy configuration of ImageMagick to perform them successfully.