menu

Questions & Answers

ImageMagick security policy 'PDF' blocking conversion

The Imagemagick security policy seems to be not allowing me perform this conversion from pdf to png. Converting other extensions seem to be working, just not from pdf. I haven't changed any of the imagemagick settings since I installed it... I am using Arch Linux, if the OS matters.

user@machine $ convert -density 300 -depth 8 -quality 90 input.pdf output.png
convert: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.
convert: no images defined `output.png' @ error/convert.c/ConvertImageCommand/3288.
Comments:
2023-01-17 00:50:21
2023-01-17 00:50:21
That link is about a FileNotFound error.
Answers(15) :

The ImageMagick change was kept after Ghostscript was fixed because applications (especially web applications) often feed arbitrary user-supplied files to ImageMagick, don't always enforce format restrictions properly, and, since Postscript (which PDF uses) is a turing-complete programming language running in a sandbox, there's always the possibility of another hole in the sandbox.

It's much better to leave things configured so ImageMagick refuses to process files that require running a program and, instead, just invoke Ghostscript directly when you intentionally want to permit Postscript rendering.

That would be accomplished by a Ghostscript command like this:

gs -dSAFER -r600 -sDEVICE=pngalpha -o foo.png myfile.pdf

Yes, this is a variation on the GhostScript command ImageMagic calls. (see ImageMagick's delegates.xml. -o is shorthand for -dBATCH -dNOPAUSE -sOutputFile=)

What's important is that ImageMagick stays locked down, you don't needlessly invoke an intermediate program, and you get more control over the rendering parameters. (eg. -r600 is the DPI to render at and changing -sDEVICE=pngalpha allows you to render directly to your desired format)

Comments:
2023-01-17 00:50:21
Wow, thanks for this really great and safe "workaround" for the issue; deserves more upvotes!
2023-01-17 00:50:21
"attempting to work around ImageMagick's PDF security issues by using Ghostscript directly is also dangerous as Ghostscript is also vulnerable to exploitation when processing malicious PDF files." from serverpilot.io/docs/how-to-install-the-imagemagick-executabl‌​e
2023-01-17 00:50:21
@Avatar Anything will be vulnerable to malicious PDF files unless you apply sufficient defense in depth, because Postscript is a turing-complete language and PDF uses a form of Postscript modified so you can seek to individual pages without rendering the entire stream. It's like saying that your web browser is vulnerable to maliciously crafted JavaScript. That article is just saying that Ghostscript is as vulnerable to 0-day attacks as Java Applets were. It's "safe" in the sense that you're less likely to expose PDF rendering to random web apps which use ImageMagick internally.
2023-01-17 00:50:21
To output to JPG format instead of PNG use -sDEVICE=jpeg.
2023-01-17 00:50:21
"Ghostscript now (as of 9.50) defaults to SAFER being active." per ghostscript.com/docs/9.54.0/Use.htm#Safer
2023-01-17 00:50:21
@Cliff Good to know, but better safe than sorry. Who knows how long it'll take to shake the last of the pre-9.50 builds out of LTS system images.

Well, I added

  <policy domain="coder" rights="read | write" pattern="PDF" />

just before </policymap> in /etc/ImageMagick-7/policy.xml and that makes it work again, but not sure about the security implications of that.

Comments:
2023-01-17 00:50:21
I believe that the PDF policy was added due to a bug in Ghostscript, which I believe has now been fixed. So it you are using the current Ghostscript, then you should be fine giving this policy read|write rights.
2023-01-17 00:50:21
I found the line <policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,PDF,XPS}" /> and just uncommented it to make it work.
2023-01-17 00:50:21
The security vulnerability that caused distributions to implement the policy is referenced here: kb.cert.org/vuls/id/332928
2023-01-17 00:50:21
@jakob-r: I suppose you commented it out... ;-)
2023-01-17 00:50:21
Make sure ghostscript is updated kb.cert.org/vuls/id/332928
2023-01-17 00:50:21
That doesn't do it for me on the current Arch.
2023-01-17 00:50:21
@Suuuehgi see soloturn's answer.
2023-01-17 00:50:21
The bug referenced by @ykaysaysReinstateMonica was addressed in Ghostscript version 9.24
2023-01-17 00:50:22
Note: if you are trying to solve this problem for conversion from EPS, allowing rights="read|write" on pattern="EPS" will accomplish nothing if you don't do the same for pattern="PS', or move the EPS line above the PS line.
2023-01-17 00:50:22
On Ubuntu 20.04 (LTS), only ImageMagick 6 is available right now, but I have an up to date version of ghostscript. Can confirm this worked for me.
2023-01-17 00:50:22
I get a ghostscript error when I enable this read/write policy: convert-im6.q16: FailedToExecuteCommand 'gs'` , anybody has a clue how to fix this? I'm using Image Magick 6.9.10-23 Q16 x86_64 20190101 on Ubuntu 20
2023-01-17 00:50:22
Isn't there a way to temporarily add this policy only for the time for the conversion?
2023-01-17 00:50:22
Worked perfectly for me! So ingenious! However in my case it was ImageMagick-6, and not 7. So you might need to check the version by navigating to /etc
2023-01-17 00:50:22
Works perfectly on Ubuntu 20.04 where convert --version shows Version: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org and gs --version shows 9.50! Now this command works to convert all jpg images into my dir to a single out.pdf!: convert *.jpg out.pdf. See: AskUbuntu: Create a single pdf from multiple text, images or pdf files.
2023-01-17 00:50:22
Has anyone gotten this working with Circle CI?
2023-01-17 00:50:22
<!-- <policy domain="coder" rights="none" pattern="PDF" /> --> was sufficient in /etc/ImageMagick-6/policy.xml on Ubuntu 20.04.

This issue is a workaround for a security vulnerability. The vulnerability has been addressed in Ghostscript 9.24, so if you have that or a newer version, you don't need the workaround anymore.

On Ubuntu 19.04 through 22.04 and probably any later versions with ImageMagick 6, here's how you fix the issue by removing that workaround:

  1. Make sure you have Ghostscript ≥9.24:

    gs --version
    
  2. If yes, just remove this whole following section from /etc/ImageMagick-6/policy.xml:

    <!-- disable ghostscript format types -->
    <policy domain="coder" rights="none" pattern="PS" />
    <policy domain="coder" rights="none" pattern="PS2" />
    <policy domain="coder" rights="none" pattern="PS3" />
    <policy domain="coder" rights="none" pattern="EPS" />
    <policy domain="coder" rights="none" pattern="PDF" />
    <policy domain="coder" rights="none" pattern="XPS" />
    

Removing just the line with pattern="PDF" inside would be enough to re-enable PDF conversion. I can't see a good reason to keep the workaround for other PostScript-based file types, though.

Attribution: @jakob-r's comment on an alternative answer. And the helpful comments here below 🙂

Comments:
2023-01-17 00:50:22
Only fix that worked for me on Ubuntu 19.04 with gs 9.26.
2023-01-17 00:50:22
sed -i '/disable ghostscript format types/,+6d' /etc/ImageMagick-6/policy.xml worked fine for me.
2023-01-17 00:50:22
Worked for Ubuntu 20.04
2023-01-17 00:50:22
Does removing this not mean you just give it all the rights? Which can be dangerous?
2023-01-17 00:50:22
@Christophvh: It means you give ImageMagick full rights back to process files with Ghostscript. This restores the file to what it was before the this temporary workaround had to be introduced for a security issue that has now been fixed.
2023-01-17 00:50:22
This is a good answer with correct and easy explanation
2023-01-17 00:50:22
Worked on Ubuntu 21.04
2023-01-17 00:50:22
Has anyone gotten this working with Circle CI?
2023-01-17 00:50:22
@ChrisHough were you ever able to resolve the problem?
2023-01-17 00:50:22
Worked for Ubuntu 22.04.
2023-01-17 00:50:22
Don't forget to restart php-fpm to commit changes made - sudo service php8.1-fpm restart
2023-01-17 00:50:22
Works fine (Ubuntu 22.04, KDE 5.24.6) - If you don't like to delete entries, just comment it out, i.e. wrap the policies which you want to disable between <!-- and -->.
2023-01-17 00:50:22
You just have to remove the line with pattern="PDF" and it'd work.

Manjaro April 2021

Just remove uncommented line inside <policymap> in /etc/ImageMagick-7/policy.xml

I was experiencing this issue with nextcloud which would fail to create thumbnails for pdf files.

However, none of the suggested steps would solve the issue for me.

Eventually I found the reason: The accepted answer did work but I had to also restart php-fpm after editing the policy.xml file:

 sudo systemctl restart php7.2-fpm.service
Comments:
2023-01-17 00:50:22
LOL. After hours trying almost every solution possible, this was the ultimate. In combination with @Stefan Seidel solution: <policy domain="coder" rights="read | write" pattern="PDF" />
2023-01-17 00:50:22
restarting php fpm was also needed for me
2023-01-17 00:50:22
If you're using plesk the name of the service is plesk-php74-fpm
2023-01-17 00:50:22
Thanks for this. In my case I had to reboot apache.

Thank you @tanius and others for the detailed answers !

I'd just add to it the following points.

  1. The path of the policy file policy.xml may change with the version of the ImageMagick like /etc/ImageMagick-6/policy.xml or /etc/ImageMagick-7/policy.xml etc. So update it accordingly.

  2. As the policy to prevent or allow the conversion for some filetypes is a security measure, you may like to reset the changes to the policy.xml after the task is done so that there is no possibilty of the corresponding attack, if the system is accessible to attackers !

Happy speedy file conversions meanwhile !

In my case i'm useing ubuntu 20.10 and the Imagick-7.

in my /etc/ImageMagick-6/policy.xml I've removed below lines, restarted my machine and I'm done.

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

On Ubuntu 19.10, I have done this in /etc/ImageMagick-6/policy.xml

uncomment this

<policy domain="module" rights="read | write" pattern="{PS,PDF,XPS}" />

and comment this

<!-- <policy domain="coder" rights="none" pattern="PDF" /> -->

After that, this command work without error

convert -thumbnail x300 -background white -alpha remove sample.pdf sample.png 

As a highly active comment by @Richard Kiefer, a simple fix is like this

$ sudo sed -i '/disable ghostscript format types/,+6d' /etc/ImageMagick-6/policy.xml

For me on Arch Linux, I had to comment this:

  <policy domain="delegate" rights="none" pattern="gs" />
Comments:
2023-01-17 00:50:22
On my system, there was two policy.xml files : /etc/ImageMagick-6/policy.xml and /etc/ImageMagick-7/policy.xml. Take care to edit the right one!
2023-01-17 00:50:22
hanks, true!! ``` lang-js > yay -F /etc/ImageMagick-7/policy.xml etc/ImageMagick-7/policy.xml is owned by extra/imagemagick 7.0.10.30-1 > yay -F /etc/ImageMagick-6/policy.xml etc/ImageMagick-6/policy.xml is owned by extra/libmagick6 6.9.11.30-1 > yay -Rs libmagick6 checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: removing libmagick6 breaks dependency 'libmagick6' required by inkscape ```
2023-01-17 00:50:22
Odd. I expected that making this rights="read|write" like other answers suggest would work, but also found that I needed to fully comment this out. For those familiar with xml, would be sweet to adjust your answer to show that "comment this" means to take <foo... /> and make it <!-- <foo... /> -->. Would spare the new user one extra search.
2023-01-17 00:50:22
As of Arch package "imagemagick" version 7.1.0.20-2 this is not needed anymore. The policy change was removed from the default config.
2023-01-17 00:50:22
this works for me, 2022, archlinux, /etc/ImageMagick-7/policy.xml

Works in Ubuntu 20.04

Add this line inside <policymap>

<policy domain="module" rights="read|write" pattern="{PS,PDF,XPS}" />

Comment these lines:

  <!--
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="PS2" />
  <policy domain="coder" rights="none" pattern="PS3" />
  <policy domain="coder" rights="none" pattern="EPS" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
   -->
Comments:
2023-01-17 00:50:22
Adding <policy domain="module" rights="read|write" pattern="{PS,PDF,XPS}" /> wasn't needed for me

As pointed out in some comments, you need to edit the policies of ImageMagick in /etc/ImageMagick-7/policy.xml. More particularly, in ArchLinux at the time of writing (05/01/2019) the following line is uncommented:

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

Just wrap it between <!-- and --> to comment it, and pdf conversion should work again.

Comments:
2023-01-17 00:50:22
make sure ghostscript is up to date kb.cert.org/vuls/id/332928
2023-01-17 00:50:23
What's the point of this functionality? To prevent users from making PDFs?
2023-01-17 00:50:23
Partially, yes. As ImageMagick is often used by websites to process uploaded files - and PDF is among one of the file formats which can basically contain any executable code - anyone with upload permissions could otherwise perform any task your web user has access to. Same if someone tricks you into personally converting a malicious PDF to any other format.
2023-01-17 00:50:23
I am outraged if the decision was prevent me from using my software because someone may find a way to cheat with it.
2023-01-17 00:50:23
@Gabriel It was more about preventing people from feeding malicious PDFs to insufficiently sanitizing image upload fields. (i.e. "Hack their site through the thumbnailer when they never intended to support PDF and Postscript to begin with" situations.)
2023-01-17 00:50:23
Has anyone gotten this working with Circle CI?
2023-01-17 00:50:23
where is the imagemagick policy.xml file on Debian 11 (bullseye)? I have Imagemagick installed in /usr/share/bug/imagemagick, there are no policy.xml file inside imagemagick directory.

For me on my archlinux system the line was already uncommented. I had to replace "none" by "read | write " to make it work.

Comments:
2023-01-17 00:50:23
make sure ghostscript is up to date kb.cert.org/vuls/id/332928
2023-01-17 00:50:23
same. I am up to date btw.
2023-01-17 00:50:23
The advice is to comment the line to disable the restriction, or, as you mentioned, define rights > none.

For my system Ubuntu 20.04 wasnt working, but for my windows 10 was working just fine.

my main job was to add subtitles to a video and generate an output mp4.

After messing around with the policy.xml file i found a "potentially" bad workaround. which is delete all contents of the policy.xml, which has worked for me and i was able to add my subtitles to the video.

Please be aware this might be a temporary fix untill you dont find a better solution.

Adding to Stefan Seidel's answer.

Well, at least in Ubuntu 20.04.2 LTS or maybe in other versions you can't really edit the policy.xml file directly in a GUI way. Here is a terminal way to edit it.

  1. Open the policy.xml file in terminal by entering this command -

    sudo nano /etc/ImageMagick-6/policy.xml

  2. Now, directly edit the file in terminal, find <policy domain="coder" rights="none" pattern="PDF" /> and replace none with read|write as shown in the picture. Then press Ctrl+X to exit.

Edit in terminal

Comments:
2023-01-17 00:50:23
Remember to ctrl+O to save before you exit
2023-01-17 00:50:23
This worked for me, Ubuntu 21.04. Thanks!
2023-01-17 00:50:23
Also works on Ubuntu 22.04.
2023-01-17 00:50:23
... or just comment out the line like so <!-- <policy domain="coder" rights="none" pattern="PDF" /> -->