search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
539 stars 48 forks source link

Convert to Trusted PDF fails on Debian-10 #6130

Closed deeplow closed 3 years ago

deeplow commented 4 years ago

Qubes OS version

R4.0 and R4.1

Affected component(s) or functionality

Brief summary

Running qvm-convert-pdf fails on debian-10 based AppVMs due to a strict default ImageMagick policy (/etc/ImageMagick-6/policy.xml)

I also tested with various combinations of fedora and debian distros:

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

It works on fedora because it has a less strict default policy.

To Reproduce

Steps to reproduce the behavior:

  1. Be on a debian-10 AppVM
  2. Have a DisposableVM set
  3. qvm-convert-pdf file.pdf (or whatever pdf file you have)

Expected behavior

$ qvm-convert-pdf file.pdf
-> Sending file to a Disposable VM...
-> Waiting for converted samples...
-> Receiving page 11 out of 11...
-> Converted PDF saved as: ./file.trusted.pdf
-> Original file saved as /home/user/QubesUntrustedPDFs/file.pdf

Actual behavior

$ qvm-convert-pdf demo.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.

Screenshots

Additional context

The discussion that originated this came from the forum.

It has been reproduced by @GWeck and Clarawolf (kudos to Clara for starting the thread and GWeck for reproducing it)

Solutions you've tried

I've managed to solve this by removing the following line from the policy:

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

But it should also be possible to replace that with:

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

So the final fix should be changing the default ImageMagick policy (/etc/ImageMagick-6/policy.xml) that ships with the qubes debian-10 template.

From my understanding, this change of policy does NOT affect the security of of the conversion to trusted.

Relevant documentation you've consulted

Related, non-duplicate issues

none

deeplow commented 4 years ago

A UX improvement may be to inform the user there is a problem with the policy. This would make life easier when the qvm-convert-pdf is used with any other distro template since users will know what to look for in order to fix it.

icequbes1 commented 4 years ago

Looks to be due to Debian patches in 6.9.10.23+dfsg-2.1+deb10u1 which also addressed around 50 CVEs (changelog: Thu, 25 Jun 2020):

Author: Steve Beattie steve.beattie@canonical.com Subject: disable ghostscript handled formats based on -SAFER insecurity

Based on Tavis Ormandy's Recommendations updated: 2019-11-11

+  <!-- 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" />
marmarek commented 4 years ago

In a generic case it looks like a good idea to disable those coders. But here we operate explicitly on a safe input with no way to inject any code for ghostscript to parse. Setting rights to "write" for PDF coder should be safe in context of qvm-convert-pdf, but in generic case may open the user to some ImageMagick vulnerabilities...

Perhaps a better option is to look at graphicsmagick instead? #5009

deeplow commented 4 years ago

But here we operate explicitly on a safe input with no way to inject any code for ghostscript to parse.

@marmarek Exactly. So ideally the there would de the default policy (strict) to prevent user foot-shooting mistakes and then "PDF write" policy specific to the qvm-convert-pdf. But I'm not sure that is possible on imagemagick. (I haven't looked to much into it)

Looks to be due to Debian patches in 6.9.10.23+dfsg-2.1+deb10u1 which also addressed around 50 CVEs

@icequbes1 So in this case here, debian has a stricter policy than fedora. Doesn't this then mean that fedora is still exposed to these CVEs? Or is it because of the outdated Debian software? Maybe I'm missing something here.

GWeck commented 4 years ago

In R4.1, if a PDF file is converted to a trusted PDF via the corresponding function, the dispvm for the conversion is created, performs the conversion, but then stays running and has to be shutdown manually.

unman commented 3 years ago

@deeplow This works for me 210610. Can you test again?

deeplow commented 3 years ago

@deeplow This works for me 210610. Can you test again?

It seems to be working for me now.

andrewdavidwong commented 3 years ago

@deeplow This works for me 210610.

Can you test again?

It seems to be working for me now.

Closing this as resolved. If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.

GWeck commented 3 years ago

On QubesR4.1, the situation is unchanged: The conversion succeeds, but the dispvm does not close and has to be shut down manually.

GWeck commented 3 years ago

Even after applying all current updates to dom0 and the debian template, the situation is unchanged. The zombie dispvm sems to be in a somewhat queer state, as shutting it down from the Qube manager crashes the Qube manager.

unman commented 3 years ago

On Sun, Jun 13, 2021 at 03:07:59AM -0700, Andrew David Wong wrote:

Reopened #6130.

This is a separate 4.1 issue, and not Debian specific.

DemiMarie commented 3 years ago

Even after applying all current updates to dom0 and the debian template, the situation is unchanged. The zombie dispvm sems to be in a somewhat queer state, as shutting it down from the Qube manager crashes the Qube manager.

Would you be willing to provide a backtrace? qubes-manager crashing is an unrelated bug, though.

andrewdavidwong commented 3 years ago

On Sun, Jun 13, 2021 at 03:07:59AM -0700, Andrew David Wong wrote:

Reopened #6130.

This is a separate 4.1 issue, and not Debian specific.

I'm guessing "this" refers to @GWeck 's comments, which prompted me to reopen this issue? And I'm guessing you're saying that the issue on which we're commenting is actually still resolved and that @GWeck is experiencing a separate bug that should be reported in a separate issue? Re-closing as resolved, then...