Error with qvm-convert-pdf

clarawolf · October 17, 2020, 12:18am

The problem

For quite some time now, I get an error message when I try to convert a PDF into a trusted PDF:

user@disp4944:~$ qvm-convert-pdf debian-handbook.pdf 
-> Sending file to a Disposable VM...
-> Waiting for converted samples...
Page 1 conversion failed (PNG->PDF): convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.

NB: Right-clicking on a PDF on nautilus to choose “Convert To Trusted PDF” gives the same error in a pop-up window.

What I found

I search the error message (convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF’ @ error/constitute.c/IsCoderAuthorized/408) on the web and it seems to be quite a common problem:

Both of those links suggest to modifiy the content of the /etc/ImageMagick-6/policy.xml file:

comment the lines before the last line (which is </policymap> ) and
add a new one : <policy domain="coder" rights="read|write" pattern="PDF,PS" />

According to https://cromwell-intl.com/open-source/pdf-not-authorized.html, the end of the resulting /etc/ImageMagick-6/policy.xml file should consequently be:

  <!--
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="EPI" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
  -->
  <policy domain="coder" rights="read|write" pattern="PDF,PS" />
</policymap>

Good news: The hack works and I am now able to convert a PDF to a trusted PDF.
Bad news: I don’t understand the security implications of this fix. Basically, I don’t understand the arguments on the web pages.

Questions

What is the problem and why did it arise?
Is my fix appropriate? I mean: Is making the same change in the templateVM (instead of in the DispVM where I was testing) the right way to definitely take securely care of this problem?
If not, why? And what should I do to fix the problem?

Thank you!

deeplow · October 17, 2020, 5:43pm

Hi @clarawolf! This happened exactly to me the other day with this PDF but never put in the effort follow it through (though I came across a similar solution to yours). (the PDF came from this discussion on Github)

Assuming XEN provides enough isolation, as far as I’m aware this should be safe, no matter what policy decisions you make on the DisposableVM that does the PDF conversion.

Even more than that, the architecture of the qubes “Convert to Trusted PDF” actually assumes the PDF is compromised and can execute arbitrary malicious code. I encourage you to read Joanna Rutkowska’s article on that process:

I don’t know much about this. But there are some components in PDFs that are typically used as for exploitation. So my hunch is that those are disabled by default and one one you tested with did have make use of one of those components. But I’m just guessing here.

@GWeck, this might also interest you since concerns a PDF uploaded that you uploaded (to github).

clarawolf · October 17, 2020, 8:08pm

Hi, @deeplow. Thanks for answering!

Since the problem arose here, it happened not for one, but for every PDF I wanted to convert.

My concern was/is: Does that modification in the policy.xml alter the conversion in a way that the resulting “Trusted PDF” could still contain a malicious piece of code?

Sure! But I am altering the sanitizer, here. Consequently, is it still effective?

I read it. Thanks! Not sure where the modification of the policy.xml file exactly fits in Joanna’s explanation, though.

Well, my understanding is that ImageMagick disables by default any actions with PS/EPS/PDF/XPS files. Indeed, that was the end of the (problematic) policy.xml:

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

But then, nobody would be able to use “convert-to-trusted-pdf” in Qubes!?

The answer to the problem?

Aaaah, I think I’ve just found something: The policy.xml is not the same in Fedora-32, where nearly everything is commented out! And I am realising that I have no problem converting a PDF with a DispVM based on Fedora-32! (My default DispVM are based on Debian)

If we assume the “convert-to-trusted-PDF” process on Fedora-32 is secure, copying ImageMagick’s policy.xml file to Debian-10 should ensure a trustworthy process on Debian-10, too.

I think we reached the end of the problem, then!
As a sanity check, can I please ask you (or anyone) to :
- post your /etc/ImageMagick-6/policy.xml from Debian-10 to compare with mine?
- try to convert to a trusted PDF in a Debian-10 DispVM to see if it fails?

Thank you so much!!

GWeck · October 18, 2020, 10:55am

I just checked the file. It was created by LbreOffice 7.0, using the Export to PDF function. So that’s nothing special - I hope at least. But probably the reply by clarawolf explains it.

GWeck · October 18, 2020, 11:18am

I tested now on R4.1 with the following results:

From a Fedora-based VM, the conversion succeeds with a Fedora-based dvm-template, as well as with a debian-based dvm-template.
From debian with a Fedora-based dvm-template, the conversion throws the error, but still creates the output file. The original file, however, is not saved in the directory QubesUntrustedPDFs, as is done on a successful conversion.
So the policy problem seems not to concern the conversion itself, which is done in the dvm, but the moving of the original file, which is done in the source VM, which should not even look into the file.
In all tests, the created dvms did not shutdown.

deeplow · October 18, 2020, 8:04pm

Thanks for checking it @GWeck! At the time, I remember having testing it with that file and another one I had laying around and the conversion only failed on yours. But I guess I must be making a confusion. Sorry about that.

@clarawolf I must have misread and wrongly though the the policy was done on the DisposableVM in which the PDF is rendered. I have done some reading an now I understand this better. The rest of this post are my findings.

Results

I’ve tried to structure here some of my results and they are consistent to both @GWeck’s and @clarawolf’s

AppVM	DisposableVM	Result
debian-10	debian-10-dvm	Error (IsCoderAuthorized/408)
debian-10	fedora-32-dvm	Error (IsCoderAuthorized/408)
fedora-32	debian-10-dvm	OK
fedora-32	fedora-32-dvm	OK

I have also tested with at least two PDFs so I don’t think it’s dependent on the PDF.

This means that from my understanding, any changes to the policy within the DispVM should not affect in the security of opening the trusted PDFs.

Conclusion

The problem is with following line on the policy on Debian 10, which prevents ImageMagick (the program behind the convert command) from writing to a PDF.

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

Security Implications

From my understanding, removing that line from the Debian 10 /etc/ImageMagick-6/policy.xml does not have any security implications since the only thing it was doing was was disabling the use of convert into a PDF and this does not affect in any way the security mechanisms of the trusted PDF conversion.

Note: I urge someone more knowledgeable to double-check my conclusions and analysis.

ImageMagick Policies

Find here a premiere on the policies

Instead of inspecting directly the file /etc/ImageMagick-6/policy.xml you may as well run the command identify -list policy

Debian 10

$ sha256sum /etc/ImageMagick-6/policy.xml 
b77ad0a0da080e552152f78ea085f273fc0f6522ba3f8c9d11a65043bf8fd0e3  /etc/ImageMagick-6/policy.xml

Content of the file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policymap [
  <!ELEMENT policymap (policy)+>
  <!ATTLIST policymap xmlns CDATA #FIXED ''>
  <!ELEMENT policy EMPTY>
  <!ATTLIST policy xmlns CDATA #FIXED '' domain NMTOKEN #REQUIRED
    name NMTOKEN #IMPLIED pattern CDATA #IMPLIED rights NMTOKEN #IMPLIED
    stealth NMTOKEN #IMPLIED value CDATA #IMPLIED>
]>
<!--
  Configure ImageMagick policies.

  Domains include system, delegate, coder, filter, path, or resource.

  Rights include none, read, write, execute and all.  Use | to combine them,
  for example: "read | write" to permit read from, or write to, a path.

  Use a glob expression as a pattern.

  Suppose we do not want users to process MPEG video images:

    <policy domain="delegate" rights="none" pattern="mpeg:decode" />

  Here we do not want users reading images from HTTP:

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

  The /repository file system is restricted to read only.  We use a glob
  expression to match all paths that start with /repository:

    <policy domain="path" rights="read" pattern="/repository/*" />

  Lets prevent users from executing any image filters:

    <policy domain="filter" rights="none" pattern="*" />

  Any large image is cached to disk rather than memory:

    <policy domain="resource" name="area" value="1GP"/>

  Define arguments for the memory, map, area, width, height and disk resources
  with SI prefixes (.e.g 100MB).  In addition, resource policies are maximums
  for each instance of ImageMagick (e.g. policy memory limit 1GB, -limit 2GB
  exceeds policy maximum so memory limit is 1GB).

  Rules are processed in order.  Here we want to restrict ImageMagick to only
  read or write a small subset of proven web-safe image types:

    <policy domain="delegate" rights="none" pattern="*" />
    <policy domain="filter" rights="none" pattern="*" />
    <policy domain="coder" rights="none" pattern="*" />
    <policy domain="coder" rights="read|write" pattern="{GIF,JPEG,PNG,WEBP}" />
-->
<policymap>
  <!-- <policy domain="system" name="shred" value="2"/> -->
  <!-- <policy domain="system" name="precision" value="6"/> -->
  <!-- <policy domain="system" name="memory-map" value="anonymous"/> -->
  <!-- <policy domain="system" name="max-memory-request" value="256MiB"/> -->
  <!-- <policy domain="resource" name="temporary-path" value="/tmp"/> -->
  <policy domain="resource" name="memory" value="256MiB"/>
  <policy domain="resource" name="map" value="512MiB"/>
  <policy domain="resource" name="width" value="16KP"/>
  <policy domain="resource" name="height" value="16KP"/>
  <!-- <policy domain="resource" name="list-length" value="128"/> -->
  <policy domain="resource" name="area" value="128MB"/>
  <policy domain="resource" name="disk" value="1GiB"/>
  <!-- <policy domain="resource" name="file" value="768"/> -->
  <!-- <policy domain="resource" name="thread" value="4"/> -->
  <!-- <policy domain="resource" name="throttle" value="0"/> -->
  <!-- <policy domain="resource" name="time" value="3600"/> -->
  <!-- <policy domain="coder" rights="none" pattern="MVG" /> -->
  <!-- <policy domain="module" rights="none" pattern="{PS,PDF,XPS}" /> -->
  <!-- <policy domain="delegate" rights="none" pattern="HTTPS" /> -->
  <!-- <policy domain="path" rights="none" pattern="@*" /> -->
  <!-- <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="pixel-cache-memory" value="anonymous"/> -->
  <!-- <policy domain="system" name="shred" value="2"/> -->
  <!-- <policy domain="system" name="precision" value="6"/> -->
  <!-- not needed due to the need to use explicitly by mvg: -->
  <!-- <policy domain="delegate" rights="none" pattern="MVG" /> -->
  <!-- use curl -->
  <policy domain="delegate" rights="none" pattern="URL" />
  <policy domain="delegate" rights="none" pattern="HTTPS" />
  <policy domain="delegate" rights="none" pattern="HTTP" />
  <!-- in order to avoid to get image with password text -->
  <policy domain="path" rights="none" pattern="@*"/>
  <!-- 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" />
</policymap>

Fedora 32

$ sha256sum /etc/ImageMagick-6/policy.xml 
8ec1c34deb6b9001c8ddf688056fa432a847c9b37d37ceedfcdf22bf4a5701ba  /etc/ImageMagick-6/policy.xml

Content of the file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policymap [
  <!ELEMENT policymap (policy)+>
  <!ATTLIST policymap xmlns CDATA #FIXED ''>
  <!ELEMENT policy EMPTY>
  <!ATTLIST policy xmlns CDATA #FIXED '' domain NMTOKEN #REQUIRED
    name NMTOKEN #IMPLIED pattern CDATA #IMPLIED rights NMTOKEN #IMPLIED
    stealth NMTOKEN #IMPLIED value CDATA #IMPLIED>
]>
<!--
  Configure ImageMagick policies.

  Domains include system, delegate, coder, filter, path, or resource.

  Rights include none, read, write, execute and all.  Use | to combine them,
  for example: "read | write" to permit read from, or write to, a path.

  Use a glob expression as a pattern.

  Suppose we do not want users to process MPEG video images:

    <policy domain="delegate" rights="none" pattern="mpeg:decode" />

  Here we do not want users reading images from HTTP:

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

  The /repository file system is restricted to read only.  We use a glob
  expression to match all paths that start with /repository:

    <policy domain="path" rights="read" pattern="/repository/*" />

  Lets prevent users from executing any image filters:

    <policy domain="filter" rights="none" pattern="*" />

  Any large image is cached to disk rather than memory:

    <policy domain="resource" name="area" value="1GP"/>

  Define arguments for the memory, map, area, width, height and disk resources
  with SI prefixes (.e.g 100MB).  In addition, resource policies are maximums
  for each instance of ImageMagick (e.g. policy memory limit 1GB, -limit 2GB
  exceeds policy maximum so memory limit is 1GB).

  Rules are processed in order.  Here we want to restrict ImageMagick to only
  read or write a small subset of proven web-safe image types:

    <policy domain="delegate" rights="none" pattern="*" />
    <policy domain="filter" rights="none" pattern="*" />
    <policy domain="coder" rights="none" pattern="*" />
    <policy domain="coder" rights="read|write" pattern="{GIF,JPEG,PNG,WEBP}" />
-->
<policymap>
  <!-- <policy domain="system" name="shred" value="2"/> -->
  <!-- <policy domain="system" name="precision" value="6"/> -->
  <!-- <policy domain="system" name="memory-map" value="anonymous"/> -->
  <!-- <policy domain="system" name="max-memory-request" value="256MiB"/> -->
  <!-- <policy domain="resource" name="temporary-path" value="/tmp"/> -->
  <!-- <policy domain="resource" name="memory" value="2GiB"/> -->
  <!-- <policy domain="resource" name="map" value="4GiB"/> -->
  <!-- <policy domain="resource" name="width" value="10KP"/> -->
  <!-- <policy domain="resource" name="height" value="10KP"/> -->
  <!-- <policy domain="resource" name="list-length" value="128"/> -->
  <!-- <policy domain="resource" name="area" value="100MP"/> -->
  <!-- <policy domain="resource" name="disk" value="16EiB"/> -->
  <!-- <policy domain="resource" name="file" value="768"/> -->
  <!-- <policy domain="resource" name="thread" value="4"/> -->
  <!-- <policy domain="resource" name="throttle" value="0"/> -->
  <!-- <policy domain="resource" name="time" value="3600"/> -->
  <!-- <policy domain="coder" rights="none" pattern="MVG" /> -->
  <!-- <policy domain="module" rights="none" pattern="{PS,PDF,XPS}" /> -->
  <!-- <policy domain="delegate" rights="none" pattern="HTTPS" /> -->
  <!-- <policy domain="path" rights="none" pattern="@*" /> -->
  <!-- <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"/> -->
</policymap>

In-depth look

I’ve spend a bit of time to understand exactly how the PDF sanitization works, in case anyone is interested (especially from the client perspective)

Let’s give here some names to the VMs to make it easier:

work - the client
disp1234 - the dispVM which does the conversion itself

Flow Diagram

From the perpective of the AppVM where you click on “convert to trusted PDF” (also know as the client) this is what it does:

Send PDF to DisposableVM (disp1234) (code)
Wait for disp1234 to start sending stuff
For each page
1. Receive RGB bitmap of page (code)
2. Convert RGB Bitmap → PNG (code)
3. Convert PNG → PDF (code ?)
Join all single-page PDF into a full PDF (code)

Disclaimer: It was a bit hard for me decipher this code, so something may be wrong above.

deeplow · October 18, 2020, 8:26pm

I’ve opened an issue report on this. Thanks to both of you!

clarawolf · October 19, 2020, 7:37pm

Thank you very much for your analysis, @deeplow.

Everything is much clearer now!