Page 1 of 1

Disabling Ghostscript in IM

Posted: 2018-08-21T12:25:11-07:00
by Imaging
We'd like to disable Ghostscript support for our ImageMagick install (using a rpm so not able to uninstall ghostscript since it is a dependency).

As best we can see, it appears that policy.xml would be the place to disable it.

We aren't sure of the exact syntax though.

Could someone please post an example of the proper syntax for completely disabling Ghostscript support?

Thanks in advance.

Re: Disabling Ghostscript in IM

Posted: 2018-08-21T12:55:05-07:00
by magick
ImageMagick best practices strongly encourages you to configure a security policy that suits your local environment. See https://www.imagemagick.org/script/security-policy.php for a detailed discussion. Relevant to this potential exploit in Ghostscript, you can restrict ImageMagick to only web-safe image formats with these policies:

Code: Select all

<policy domain="delegate" rights="none" pattern="*" />
<policy domain="coder" rights="none" pattern="*" />
<policy domain="coder" rights="read | write" pattern="{GIF,JPEG,PNG,WEBP}" />
If you just want to disable Ghostscript, use this policy:

Code: Select all

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

Re: Disabling Ghostscript in IM

Posted: 2018-08-21T12:58:40-07:00
by Imaging
Thanks for the response. That appears to disable all delegates. We are only interested in disabling Ghostscript support. How would we do that specifically?

Re: Disabling Ghostscript in IM

Posted: 2018-08-21T13:00:00-07:00
by magick
We corrected our original posting. You can also uninstall Ghostscript from your system.

Re: Disabling Ghostscript in IM

Posted: 2018-08-21T13:07:45-07:00
by Imaging
Thank you for the update. Uninstalling isn't an option for us since ghostscript is a dependency for our rpm based IM installation.

Just to make sure, does the above disabling of just the specific coders (versus disabling ghostscript), also preclude any nested image issues? From a post about the GS exploit:

__

A small note. Both ImageMagick and GraphicsMagick process various file
formats that can nest a different image file inside of them. These are very
frequently implemented with a call to ReadImage(), with no checking that
it's the expected file format. (As a result, the fuzzer finds various
impressive chains, with sometimes 3 different image formats nested inside
of each other).

The conclusion of this is that people _must not_ attempt to do their own
format detection and then pass the data to IM/GM, because this can be
bypassed with nested formats. It's imperative that GS truly be disabled
with either policy.xml or by uninstall GS.

__

Thank you.

Re: Disabling Ghostscript in IM

Posted: 2018-08-21T13:18:36-07:00
by magick
Its possible that older versions of ImageMagick cannot process a glob pattern. If so, you can disable the formats one at at time, like this:

Code: Select all

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="PDF" />
If there is a nested image, it is still checked against the security policy before it can be read. So you should be safe. We are not aware of any exploits that can bypass the security subsystem in ImageMagick. If you identify such an exploit, let us know and we will apply a patch or enhance the security subsystem likely within just a few hours. There is no priority higher for the ImagMagick development team than resolving security issues.

Re: Disabling Ghostscript in IM

Posted: 2018-08-21T13:26:12-07:00
by Imaging
Great, thank you for the clarification.

Re: Disabling Ghostscript in IM

Posted: 2018-08-23T08:52:09-07:00
by Imaging
One additional note: It appears that PS2 and PS3 coders need to be disabled as well per:

https://www.kb.cert.org/vuls/id/332928

Re: Disabling Ghostscript in IM

Posted: 2018-08-23T12:21:42-07:00
by dlemstra
I don't understand why the CVE claims that they need to be disabled. We don't have support for reading files in the PS2 and the PS3 coders.

Re: Disabling Ghostscript in IM

Posted: 2018-08-24T11:07:57-07:00
by Imaging
Perhaps it has to do with:

http://www.openwall.com/lists/oss-secur ... 8/08/23/13

that was mentioned in the original issue thread.