ImageMagick security policy 'PDF' blocking conversion

A

15

825

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.

Allred answered 25/10, 2018 at 21:25 Comment(2)

Possible duplicate of ImageMagick not authorized to convert PDF to an image – Schaefer 23/11, 2018 at 12:11

That link is about a FileNotFound error. – Sirotek 23/6, 2022 at 9:25

G

44

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)

Greggs answered 12/4, 2021 at 21:58 Comment(6)

Wow, thanks for this really great and safe "workaround" for the issue; deserves more upvotes! – Bartholomeus 5/9, 2021 at 21:37

"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-executable – Cerebrum 21/2, 2022 at 8:17

@Cerebrum 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. – Greggs 21/2, 2022 at 10:26

To output to JPG format instead of PNG use -sDEVICE=jpeg. – Mchugh 11/8, 2022 at 5:35

"Ghostscript now (as of 9.50) defaults to SAFER being active." per ghostscript.com/docs/9.54.0/Use.htm#Safer – Cablet 5/1, 2023 at 19:48

@Cablet 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. – Greggs 6/1, 2023 at 3:45

U

874

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.

Unbraid answered 6/11, 2018 at 21:20 Comment(20)

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. – Youlandayoulton 6/11, 2018 at 21:43

I found the line <policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,PDF,XPS}" /> and just uncommented it to make it work. – Inlet 7/12, 2018 at 12:18

The security vulnerability that caused distributions to implement the policy is referenced here: kb.cert.org/vuls/id/332928 – Unfleshly 8/1, 2019 at 23:58

Make sure ghostscript is updated kb.cert.org/vuls/id/332928 – Awhile 5/3, 2019 at 9:35

That doesn't do it for me on the current Arch. – Primp 5/11, 2019 at 18:1

@Primp see soloturn's answer. – Whirlabout 21/11, 2019 at 13:33

See #52862446 – Youlandayoulton 5/2, 2020 at 17:28

The bug referenced by @ykaysaysReinstateMonica was addressed in Ghostscript version 9.24 – Pentecost 11/5, 2020 at 22:18

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. – Fretful 24/7, 2020 at 15:57

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. – Goar 27/9, 2020 at 23:9

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 – Chur 28/9, 2020 at 6:51

Isn't there a way to temporarily add this policy only for the time for the conversion? – Nur 29/6, 2021 at 19:42

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 – Winkle 25/8, 2021 at 19:8

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. – Hydrogenate 8/1, 2022 at 7:30

Has anyone gotten this working with Circle CI? – Unifoliolate 18/1, 2022 at 17:24

 was sufficient in /etc/ImageMagick-6/policy.xml on Ubuntu 20.04. – Troytroyer 26/10, 2022 at 16:20

Don't forget to restart your server. – Souffle 13/2, 2023 at 19:38

I ran into this while using pdfplumber package's to_image() function. I had to reload the package after applying the policy changes. – Tripletail 16/6, 2023 at 0:0

Please edit the answer to mention that the file could be named as /etc/ImageMagick-6/policy.xml, like suggested by users johnrbnz, cerin, etc. – Saying 27/6, 2023 at 12:20

All answers seem to refer to configuration file /etc/ImageMagick-{6,7}/policy.xml but you might have a local config at ~/.config/ImageMagick/policy.xml like I did because I had played with some settings few years ago and forgot that I had it. Changing /etc... had no effect as my ~/.config... was a full copy of the base config and overrode any changes I made to to /etc.... Lesson learned. – Benedick 3/7, 2023 at 20:40

P

592

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:

Make sure you have Ghostscript ≥9.24:
```
gs --version
```

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" />

Details: Removing just the line with pattern="PDF" inside would be enough to re-enable PDF conversion. On my computer, I removed the lines for the other PostScript-based filetypes as well just because I can't see a reason to prevent Image Magick from working with such files. (Talking about a personal computer only. On a web server, you might consider it dangerous as PostScript-based files can contain scripts … actually, PostScript is script.)

Attribution: @jakob-r's comment on another answer. Plus the helpful comments below ↓ 🙂

Paratrooper answered 5/12, 2019 at 10:36 Comment(14)

Only fix that worked for me on Ubuntu 19.04 with gs 9.26. – Flagging 20/12, 2019 at 12:32

sed -i '/disable ghostscript format types/,+6d' /etc/ImageMagick-6/policy.xml worked fine for me. – Taima 2/7, 2020 at 15:41

Worked for Ubuntu 20.04 – Pronounce 9/7, 2020 at 0:41

Does removing this not mean you just give it all the rights? Which can be dangerous? – Hanschen 1/8, 2020 at 13:54

@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. – Paratrooper 1/8, 2020 at 14:51

This is a good answer with correct and easy explanation – Wellnigh 23/3, 2021 at 5:38

Worked on Ubuntu 21.04 – Bathos 12/5, 2021 at 16:32

Has anyone gotten this working with Circle CI? – Unifoliolate 18/1, 2022 at 17:24

@ChrisHough were you ever able to resolve the problem? – Maritsa 11/4, 2022 at 14:1

Worked for Ubuntu 22.04. – Neurophysiology 10/8, 2022 at 16:8

Don't forget to restart php-fpm to commit changes made - sudo service php8.1-fpm restart – Dislocate 30/8, 2022 at 3:18

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 . – Stereochemistry 14/9, 2022 at 17:17

You just have to remove the line with pattern="PDF" and it'd work. – Centrifuge 10/1, 2023 at 18:51

worked for me, do one thing, after making change in policy.xml restart server sudo service apache2 restart – Kuhn 20/6, 2023 at 7:54

H

181

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  to comment it, and pdf conversion should work again.

Hat answered 5/1, 2019 at 21:46 Comment(8)

make sure ghostscript is up to date kb.cert.org/vuls/id/332928 – Awhile 5/3, 2019 at 9:35

What's the point of this functionality? To prevent users from making PDFs? – Acosta 27/3, 2019 at 1:22

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. – Guggle 14/4, 2019 at 10:37

I am outraged if the decision was prevent me from using my software because someone may find a way to cheat with it. – Brita 16/6, 2021 at 20:55

@Brita 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.) – Greggs 8/10, 2021 at 11:30

Has anyone gotten this working with Circle CI? – Unifoliolate 18/1, 2022 at 17:24

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. – Winded 11/1, 2023 at 22:9

@Winded Assuming you're using the ImageMagick version that is bundled with Debian 11, /etc/ImageMagick-6/policy.xml. Use sudoedit to modify the file. – Jarl 21/2, 2023 at 8:59

H

58

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

  <policy domain="delegate" rights="none" pattern="gs" />

Hod answered 17/10, 2019 at 18:41 Comment(5)

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! – Mcmurray 3/6, 2020 at 9:38

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 ``` – Hod 13/12, 2020 at 0:55

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 . Would spare the new user one extra search. – Grotius 24/11, 2021 at 22:59

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. – Crissum 30/1, 2022 at 17:32

this works for me, 2022, archlinux, /etc/ImageMagick-7/policy.xml – Platy 9/3, 2022 at 5:24

G

44

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)

Greggs answered 12/4, 2021 at 21:58 Comment(6)

Wow, thanks for this really great and safe "workaround" for the issue; deserves more upvotes! – Bartholomeus 5/9, 2021 at 21:37

"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-executable – Cerebrum 21/2, 2022 at 8:17

@Cerebrum 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. – Greggs 21/2, 2022 at 10:26

To output to JPG format instead of PNG use -sDEVICE=jpeg. – Mchugh 11/8, 2022 at 5:35

"Ghostscript now (as of 9.50) defaults to SAFER being active." per ghostscript.com/docs/9.54.0/Use.htm#Safer – Cablet 5/1, 2023 at 19:48

@Cablet 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. – Greggs 6/1, 2023 at 3:45

Z

39

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

Zhukov answered 7/12, 2018 at 22:50 Comment(3)

make sure ghostscript is up to date kb.cert.org/vuls/id/332928 – Awhile 5/3, 2019 at 9:35

same. I am up to date btw. – Bigmouth 27/5, 2019 at 4:25

The advice is to comment the line to disable the restriction, or, as you mentioned, define rights > none. – Bartholomeus 5/9, 2021 at 21:32

S

31

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" />
   -->

Shredding answered 10/10, 2020 at 7:49 Comment(1)

Adding <policy domain="module" rights="read|write" pattern="{PS,PDF,XPS}" /> wasn't needed for me – Aneto 13/11, 2020 at 4:41

H

26

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

Howund answered 12/10, 2021 at 5:40 Comment(0)

I

25

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.

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

sudo nano /etc/ImageMagick-6/policy.xml
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.

Integrate answered 19/2, 2021 at 6:18 Comment(4)

Remember to ctrl+O to save before you exit – Protractor 1/6, 2021 at 8:19

This worked for me, Ubuntu 21.04. Thanks! – Bechler 1/8, 2021 at 7:19

Also works on Ubuntu 22.04. – Heulandite 22/8, 2022 at 18:50

... or just comment out the line like so  – Troytroyer 26/10, 2022 at 16:22

C

18

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

Crosier answered 26/10, 2019 at 8:24 Comment(1)

August 2023: Devuan Daedalus: This works! – Comment 16/8, 2023 at 7:13

C

16

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

Calicle answered 5/2, 2020 at 9:32 Comment(4)

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" /> – Prance 19/10, 2020 at 21:49

restarting php fpm was also needed for me – Lilienthal 13/1, 2021 at 17:17

If you're using plesk the name of the service is plesk-php74-fpm – Masterful 2/2, 2021 at 17:40

Thanks for this. In my case I had to reboot apache. – Pratte 30/9, 2021 at 9:59

R

10

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" />

Roberto answered 19/1, 2022 at 11:27 Comment(1)

Restart no need. Editing policy.xml only is enough. Ubuntu 22. – Makebelieve 14/3 at 5:22

R

4

Manjaro April 2021

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

Rodrich answered 23/4, 2021 at 19:12 Comment(0)

H

1

Thank you @tanius and others for the detailed answers !

I'd just add to it the following points.

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.
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 !

Hoffarth answered 1/8, 2022 at 7:32 Comment(0)

L

0

For those who are struggling with PHP returning "attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/413" error, after changing policy.xml you need to re-install php-imagick module!! I've spent hours playing with policy.xml and restarting Apache, but only re-installing php-imagick helped:

policy.xml:

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

And then

sudo apt remove php-imagick
sudo apt update
sudo apt install php-imagick

Leathery answered 15/3 at 11:23 Comment(0)

Recommended topics

Hot tags