Hello,

Since the upgrade from imagemagick from "8:6.9.10.23+dfsg-2.1" to
"8:6.9.10.23+dfsg-2.1+deb10u1" I obtain an error when converting an
image from jpg to pdf.

I execute the following command-line:

And I obtain the following error:

It makes the program I use to read my mail through OCR (I'm
visual-impaired) failed at the mentioned command. I was forced to
downgrade to make it working again.

Best regards,
Alex.

Hello,

I found that I had to comment the following line inside
/etc/ImageMagick-6/policy.xml to make image->PDF conversion work again:

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

Is this because of a ghostscript vulnerability? Could this please be
re-enabled as soon as that issue is fixed, and I also suggest
mentioning it in the NEWS file for imagemagick. I guess the possible
risk of attack is very different between web servers and untrusted
input, and desktop users?

Thank you,
Viktor.

Additional information from upstream at
https://imagemagick.org/discourse-server/viewtopic.php?t=36287
suggests it was disabled because of something in ghostscript 9.26

I think buster already has 9.27 from security so I think we could update
the imagemagick default configuration. Is there good reason not to?

Thanks,

Hi,

The PDF policy restriction is also in effect on Debian stable even
though that release ships with Ghostscript 9.27, which online sources
suggest is safe. [1]

Converting images to PDF is a very common functionality. Please
provide a backport with the attached patch, or similar. Thanks!

Kind regards
Felix Lechner

[1] https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion

Another package negatively affected with the current restrictions
is lyx - see bugs 911236 and 975678.

PDF and EPS coders need to be allowed for normal functionality.

Pavel

Hi,

Cc'in the security-team alias.

It is actually unlikely for the moment that we will revert the
200-disable-ghostscript-formats.patch patch again, which was firstly
included in the 8:6.9.10.23+dfsg-2.1+deb10u1 upload. It does mitigates
in general problems with the ghostscript handled formats, e.g. the
(new) CVE-2020-29599, cf.
https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html
.

We follow here only what other distributions have done earlier, I
believe SuSE has such and as well Ubuntu, from which the mentioned
patch was actually merged in in the last update, TTBOMK.

Regards,
Salvatore

Hi,

I agree with salvatore, that in general disabling pdf is the safer solution.

I am slowly recovering from work debt due to covid  19 lockdown in
France (i was locked down three month, and I could only work by night
for payjob so debian work was not done), but I will accept patch.

The solution of this tradeoff problem is a debconf question. I will accept patch

Bastien

Yeah, this was intentionally, but I missed an entry for this in debian/changelog.

I don't think we need debconf here, policy.xml is a conffile, which can be edited locally
if one accepts the risk or uses Ghostscript with trusted input only.

Cheers,
        Moritz

Does this only affect ghostscript or any action involving external commands?

Why is backtick in the whitelist?

I don't feel that is a great reason. We wouldn't have debs and so on if it was generally applicable.

Hope that helps,
MJR (mobile)

Hello!

As I ran into this issue I am giving here a short summary from what I
understand to avoid that others have to re-read everything again:

AFAIU, there are two issues, one is related to Ghostscript, and one to
ImageMagick itself.

Ghostscript
===========

According to https://www.kb.cert.org/vuls/id/332928/ the issue is
addressed in Ghostscript 9.24.

Except for Debian old-old-stable, Debian does ship versions above 9.24:
https://tracker.debian.org/pkg/ghostscript

ImageMagick
===========

Issue described here:
https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html

This is fixed in ImageMagick 6.9.11 and later, which is available in
Bullseye but not earlier versions of Debian.

Current status reflected there:
https://security-tracker.debian.org/tracker/CVE-2020-29599


  - ulrike

Hello,

According to the above, and all I've read, the
security issue that blocked operations on PDFs
is no longer present in bullseye.  Not in
gs and not in imagemagick.

Unless there's some new security issue
please revert the patch and close this bug to
make functionality available.

Regards,

Karl <kop@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Dear Maintainer,

I am still running into this issue when using pdfsandwich to do automatic ocr
on my pdf files.

Since the security issues seem to be fixed, I would also appreciate allowing
editing of pdfs by default again.

Thanks for your efforts!

Regards from Germany,
MGies

Still getting this error in 2022, despite the bug having been closed years
ago, and having never existed in debian stable.

34710,4> mogrify -format pdf -- *png
mogrify-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.


This makes the package rather useless for the vast majority of uses, which
is converting trusted data.  We're not all running public facing
webservers accepting unsanitised data from the public.  Some of us use our
computers to do useful things too.