# 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 policy is open by default. This affords maximum utility for ImageMagick installations that run in a sandboxed environment, perhaps in a Docker instance, or behind a firewall where security risks are greatly diminished as compared to a public website.

Security is a trade-off between a secure environment and convenience. If you want ImageMagick to be optimally secure, you could, for example, limit ImageMagick to only read or write web safe images (e.g. GIF, JPEG, PNG). However, ImageMagick provides for a more secure option by adjusting the security policy per the requirements of your local environment or organizational policies. The security policy covers areas such as memory, which paths to read or write, how many images are permitted in an image sequence, how long a workflow can run, how much disk the image pixels can consume, a secret passphrase for remote connections, which coders are permitted or denied, and others. These policies should provide robust coverage to not only secure your environment per your requirements but also ensure ImageMagick remains a good citizen (e.g. prevent thrashing with large images) in your local environment.

As an example, suppose you download an image from the internet and unbeknownst to you its been crafted to generate a 20000 by 20000 pixel image. ImageMagick attempts to allocate enough resources (memory, disk) and your system will likely deny the resource request and exit. However, its also possible that your computer might be temporarily sluggish or unavailable or ImageMagick may abort. To prevent such a scenario, you can set limits in the policy.xml configuration file. You might wonder why ImageMagick does not already include reasonable limits? Simply because what is reasonable in your environment, might not be reasonable to someone else. For example, you may have ImageMagick sandboxed where security is not a concern, whereas another user may use ImageMagick to process images on their publically accessible website. Or ImageMagick is runs on a host with 1TB of memory whereas another ImageMagick instance runs on a tablet. By policy, permitting giga-pixel image processing on the large memory host makes sense, not so much for the resource constrained tablet. If you utilize ImageMagick from a public website, you may want to increase security by preventing usage of the MVG or HTTPS coders. Only you can decide what are reasonable limits taking in consideration your environment. We provide this policy with reasonable limits and encourage you to modify it to suit your local environment:

    <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="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="module" rights="none" pattern="URL" />
      <policy domain="coder" rights="write" pattern="{MSVG,MVG,PS,PDF,XPS}" />
      <policy domain="cache" name="memory-map" value="anonymous"/>
      <policy domain="cache" name="synchronize" value="true"/>
      <policy domain="cache" name="shared-secret" value="passphrase" stealth="True"/>
      <policy domain="system" name="shred" value="1"/>
    </policymap>

Since we process multiple simultaneous sessions, we do not want any one session consuming all the available memory. With this policy, large images are cached to disk. If the image is too large and exceeds the pixel cache disk limit, the program exits. In addition, we place a time limit to prevent any run-away processing tasks. If any one image has a width or height that exceeds 8192 pixels or if an image sequence exceeds 32 frames, an exception is thrown and processing stops. As of ImageMagick 6.9.4-6, you can prevent the use of any delegate or all delegates (set the glob pattern to "*"). Note, prior to these releases, use a domain of `coder` to prevent delegate usage (e.g. `domain="coder" rights="none" pattern="HTTPS"`). We prevent users from executing any image filters. The policy also prevents indirect reads. If you want to, for example, read text from a file (e.g. `caption:@myCaption.txt`), you'll need to disable the `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:

    $ convert ../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 6.9.7-9, 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, you can still write them:

    <policy domain="coder" rights="write" pattern="{PDF,PS,PS2,PS3,XPS}" />

As of ImageMagick 6.9.9-11, 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 6.1.12-53) 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 6.9.9-0 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 6.9.9-35, 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 6.9.8-10, you can programmatically set the ImageMagick security policy with SetMagickSecurityPolicy() (MagickCore) or MagickSetSecurityPolicy() (MagickWand).

As of ImageMagick version 6.9.10-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 6.9-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:

    $ identify -list policy
    Path: ImageMagick-6/policy.xml
      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: Cache
        name: memory-map
        value: anonymous
      Policy: Cache
        name: synchronize
        value: true
      Policy: Coder
        rights: Write
        pattern: {HTTP,HTTPS,MVG,PS,EPS,PDF,XPS}
      Policy: Filter
        rights: None
        pattern: *
      Policy: Path
        rights: None
        pattern: @*
      Policy: System
        name: font
        value: ImageMagick-6/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 firsts preallocates the disk file, which is much faster than fully populating the file with zeros. To further increase performance, we memory-map the file on disk. With memory-mapping, we get an increase in performance (up to 5x), however, there remains a possibility that as the disk file is populated, it may run out of free space. The OS then throws a SIGBUS signal which prevents ImageMagick from continuing. To prevent a SIGBUS, 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 configurat ion files. To define your security policy, you must instead edit the `magick/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.

In addition to the security policy, you can make ImageMagick safer by ...

- keeping ImageMagick up-to-date. The latest releases have fixes for any security flaws we discovered in the past;
- sanitizing any filenames or command line options you pass to ImageMagick;
- running ImageMagick in a sanitized software container such as Docker;
- running ImageMagick as the least-privileged user (e.g. 'nobody');
- explicitly setting the image file type. For example, use the filename `png:image.png` rather than `image.png`. Without an explicit image type in the filename, ImageMagick guesses the image type.
- do not create temporary files in shared directories, instead specify a private area to store only ImageMagick temporary files by setting the `temporary-path` security policy or the `-define registry:temporary-path=/data/magick` command-line option.