Security Policy
Security Policy • Pixel Cache Synchronize Policy • Zero Configuration Security Policy • Other Security Considerations
It is strongly recommended to establish a security policy suitable for your local environment before utilizing ImageMagick.
The default policy is open, which is useful for ImageMagick installations running in a secure environment, such as in a Docker container or behind a firewall.
ImageMagick is a tool that allows you to manipulate images. While it offers a range of features and capabilities, there is often a trade-off between security and convenience. To ensure optimal security, you can restrict ImageMagick to only reading or writing web-safe image formats like GIF, JPEG, and PNG. Alternatively, you can customize the security policy to fit the needs of your local environment or organizational policies. This policy can include details such as memory usage limits, allowed paths for reading and writing, limits on the number of images in a sequence, maximum workflow runtime, allowed disk space for image pixels, a secret passphrase for remote connections, and which coders are permitted or denied. By customizing the security policy, you can help secure your environment and ensure that ImageMagick is a responsible member of your local system, such as by preventing overloading with large images.
It is important to set limits on ImageMagick's resource usage to prevent potentially harmful situations. For example, if you accidentally download an image from the internet that has been crafted to generate a very large image (e.g., 20000 by 20000 pixels), ImageMagick may try to allocate the necessary resources (such as memory and disk space) and your system may deny the request or cause the program to exit. Alternatively, your computer may become temporarily slow or unresponsive, or ImageMagick may be forced to abort. To avoid such situations, you can set limits in the policy.xml configuration file.
Keep in mind that what is considered reasonable for one environment may not be suitable for another. For example, you may have ImageMagick sandboxed in a secure environment, while someone else may use it to process images on a publicly accessible website. Or, ImageMagick may be running on a host with a lot of memory, while another instance is running on a device with limited resources. In the case of the host with large memory, it may make sense to allow large image processing, but not on the device with limited resources. If you are using ImageMagick on a public website, you may want to increase security by disabling certain coders such as MVG or HTTPS.
To help you get started, ImageMagick provides a default policy with reasonable limits, but it is recommended that you modify it to suit your local environment. For example, you may want to set limits on memory usage, allowable paths for reading and writing, the number of images allowed in a sequence, the maximum time a workflow can run, and the amount of disk space allowed for image pixels. Ultimately, it is up to you to decide what limits are appropriate based on your specific environment and needs.
<policymap>
<!-- temporary path must be a preexisting writable directory -->
<policy domain="resource" name="temporary-path" value="/data/magick"/>
<policy domain="resource" name="memory" value="256MiB"/>
<policy domain="resource" name="list-length" value="32"/>
<policy domain="resource" name="width" value="8KP"/>
<policy domain="resource" name="height" value="8KP"/>
<policy domain="resource" name="map" value="512MiB"/>
<policy domain="resource" name="area" value="16KP"/>
<policy domain="resource" name="disk" value="1GiB"/>
<policy domain="resource" name="file" value="768"/>
<policy domain="resource" name="thread" value="2"/>
<policy domain="resource" name="time" value="120"/>
<policy domain="module" rights="none" pattern="URL" />
<policy domain="coder" rights="write" pattern="{MSVG,MVG,PS,PDF,XPS}" />
<policy domain="filter" rights="none" pattern="*" />
<policy domain="path" rights="none" pattern="-"/> <!-- don't read/write from/to stdin/stdout -->
<policy domain="path" rights="none" pattern="/etc/*"/> <!-- don't read sensitive paths -->
<policy domain="path" rights="none" pattern="@*"/> <!-- indirect reads not permitted -->
<policy domain="cache" name="memory-map" value="anonymous"/>
<policy domain="cache" name="synchronize" value="true"/>
<policy domain="cache" name="shared-secret" value="my-secret-passphrase" stealth="True"/>
<policy domain="system" name="shred" value="1"/>
</policymap>
To prevent one session from consuming all available memory when processing multiple sessions at the same time, large images are cached to disk with this policy. If an image exceeds the pixel cache disk limit, the program will exit. Additionally, a time limit has been set to prevent any processing tasks from running for too long. If an image has a width or height larger than 8192 pixels, or if an image sequence has more than 32 frames, processing will stop and an exception will be thrown.
Starting with ImageMagick 7.0.1-8, you can prevent the use of any delegate or all delegates (by setting the pattern to "*"). Prior to these releases, you can use the domain of coder and set rights to none and the glob pattern to HTTPS to prevent delegate usage. Additionally, users are prevented from executing any image filters and from performing indirect reads. If you want to, for example, read text from a file (e.g. caption:@myCaption.txt), you'll need to disable this path policy.
Policy glob patterns are case sensitive. To get expected behavior, coders and modules must be upper-case (e.g. "EPS" not "eps") or use a case-insensitive pattern such as [Pp][Nn][Gg].
Here is what you can expect when you restrict the HTTPS coder, for example:
$ magick ../images/wizard.png wizard.jpg convert: attempt to perform an operation not allowed by the security policy `HTTPS' convert: no images defined `wizard.jpg'
As of ImageMagick version 7.0.4-7, you can conveniently deny access to all delegates and coders except for a small subset of proven web-safe image types. For example,
<policy domain="delegate" rights="none" pattern="*" />
<policy domain="module" rights="none" pattern="*" />
<policy domain="module" rights="read | write" pattern="{GIF,JPEG,PNG,WEBP}" />
The module policy enables or disables a complete module for both read or write. To just read or write an image format, use the coder policy instead. For example, we disable reading just a few Postscript related formats, however, you can still write them:
<policy domain="coder" rights="write" pattern="{PDF,PS,PS2,PS3,XPS}" />
As of ImageMagick 7.0.7-0, you can allocate the pixel cache and some internal buffers with anonymous memory mapping rather than from heap. As a consequence, the pixels are initialized to zero resulting in a minor performance penalty. You can also jumble the contents of certain memory buffers (requires version 7.1.0-38) and temporary files before they are freed or deleted. The shred value is the number of times to replace content with random data. For example,
<policy domain="system" name="memory-map" value="anonymous"/> <policy domain="cache" name="memory-map" value="anonymous"/> <policy domain="system" name="shred" value="1"/>
For performance reasons, the first pass is fast by repeating the random sequence as necessary to overwrite the contents of the buffer or file. Subsequent passes are an order of magnitude slower, but generate cryptographically strong random bytes for the length of the buffer or file.
Some image processing algorithms (e.g. wavelet transform) might consume a substantial amount of memory to complete. ImageMagick maintains a separate memory pool for these large resource requests and as of 7.0.6-1 permits you to set a maximum request limit. If the limit is exceeded, the allocation is instead memory-mapped on disk. Here we limit the maximum memory request by policy:
<policy domain="system" name="max-memory-request" value="256MiB"/>
As of ImageMagick version 7.0.4-23, you can limit the maximum number of images in a sequence. For example, to limit an image sequence to at most 64 frames, use:
<policy domain="resource" name="list-length" value="64"/>
Note, numeric values in policies are floating-point with an optional SI prefix (e.g., 10MiB).
For additional details about resource limits and the policy configuration file, read Resources and Architecture.
As of ImageMagick 7.0.6-0, you can programmatically set the ImageMagick security policy with SetMagickSecurityPolicy() (MagickCore) or MagickSetSecurityPolicy() (MagickWand).
As of ImageMagick version 7.0.8-11, you can set a module security policy. For example, to prevent Postscript or PDF interpretation, use:
<policy domain="module" rights="none" pattern="{ps,pdf,xps}/>
As of ImageMagick version 7.0-10-52, you can set a font policy. Specify a path to a Unicode font that ImageMagick defaults to whenever the user does not specify a font preference:
<policy domain="system" name="font" value="/usr/share/fonts/arial-unicode.ttf"/>
Note, in file path glob patterns, use the backslash character (\) to escape characters that would otherwise be interpreted as special characters. For example:
<policy domain="path" rights="none" pattern="c:\\\\*"/>
You can verify your policy changes are in effect with this command:
$ magick identify -list policy
Path: ImageMagick-7/policy.xml
Policy: Cache
name: memory-map
value: anonymous
Policy: Cache
name: synchronize
value: true
Policy: Resource
name: list-length
value: 32
Policy: Resource
name: time
value: 120
Policy: Resource
name: thread
value: 2
Policy: Resource
name: file
value: 768
Policy: Resource
name: disk
value: 1GiB
Policy: Resource
name: map
value: 512MiB
Policy: Resource
name: memory
value: 256MiB
Policy: Resource
name: area
value: 16KP
Policy: Resource
name: height
value: 8KP
Policy: Resource
name: width
value: 8KP
Policy: Resource
name: temporary-path
value: /opt/tmp
Policy: Coder
rights: Write
pattern: {HTTP,HTTPS,MVG,PS,PDF}
Policy: Filter
rights: None
pattern: *
Policy: Path
rights: None
pattern: @*
Policy: System
name: font
value: ImageMagick-7/arial-unicode.ttf
Path: [built-in]
Policy: Undefined
rights: None
Notice the shared-secret policy is not listed due to the stealth property.
Doyensec provides a policy evaluator tool that can assist you in designing and auditing your security policy. The tool is found at imagemagick-secevaluator.doyensec.com.
Pixel Cache Synchronize Policy
When writing image pixels to disk, ImageMagick first preallocates the disk file, which is faster than fully populating the file with zeros. To improve performance even further, the file is memory-mapped on disk. This can result in an increase in performance of up to 5 times, but there is a possibility that the disk file may run out of free space as it is populated, causing the operating system (OS) to throw a SIGBUS signal which prevents ImageMagick from continuing. To prevent a SIGBUS signal from occurring, use this security policy:
<policy domain="cache" name="synchronize" value="True"/>
Set to True to ensure all image data is fully flushed and synchronized to disk. There is a performance penalty, however, the benefits include ensuring a valid image file in the event of a system crash and early reporting if there is not enough disk space for the image pixel cache.
Zero Configuration Security Policy
A zero configuration build of ImageMagick does not permit external configuration files. To define your security policy, you must instead edit the MagickCore/policy-private.h source module, add your policy statements, and then build the ImageMagick distribution. Here is an example zero configuration security policy:
static const char *ZeroConfigurationPolicy = \ "<policymap> \ <policy domain=\"coder\" rights=\"none\" pattern=\"MVG\"/> \ </policymap>";
Other Security Considerations
If you spot a security flaw in ImageMagick, post your concern as an issue to GitHub. Be sure to include how to reproduce the security flaw and a link to any images needed to reproduce the flaw. Alternatively, contact us and select Security Issue as the issue.
There are several ways to keep ImageMagick safer:
- Use web-safe image formats: Limiting ImageMagick to only reading or writing web-safe image formats like GIF, JPEG, and PNG can help increase security.
- Customize the security policy: You can customize the security policy to fit the needs of your local environment or organizational policies. This policy can cover aspects such as memory usage, allowable paths for reading and writing, the number of images allowed in a sequence, the maximum time a workflow can run, the amount of disk space allowed for image pixels, a secret passphrase for remote connections, and which coders are permitted or denied.
- Set limits on resource usage: You can set limits on resources such as memory usage, disk space, and workflow runtime to prevent potentially harmful situations.
- Use sandboxing: Sandboxing is a security technique that allows you to run a program in a restricted environment to prevent it from accessing sensitive information or making changes to the system.
- Disable potentially dangerous coders: If you are using ImageMagick on a public website, you may want to increase security by disabling certain coders such as MVG or HTTPS.
- Prevent execution of image filters and indirect reads: You can prevent users from executing image filters and performing indirect reads to increase security.
- Use a current version of ImageMagick: It is important to use a current version of ImageMagick to take advantage of the latest security fixes and updates.