3 ms·

Related: https://dangerzone.rocks/ https://dangerzone.rocks/ https://github.com/freedomofpress/dangerzone https://github.com/freedomofpress/dangerzone > Take

Related: https://dangerzone.rocks/ https://dangerzone.rocks/ https://github.com/freedomofpress/dangerzone https://github.com/freedomofpress/dangerzone > Take potentially dangerous PDFs, office documents, or images and convert them to safe PDFs. From the learn more about page: > Dangerzone was inspired by TrustedPDF but it works in non-Qubes operating systems, which is important, because most of the journalists I know use Macs and probably won’t be jumping to Qubes for some time. > It uses gVisor sandboxes running in Linux containers to open dangerous documents, instead of virtual machines. And it also adds some features that TrustedPDF doesn’t have: it works with any office documents, not just PDFs; it uses optical character recognition (OCR) to make the safe PDF have a searchable text layer; and it compresses the final safe PDF. Previously (announcement and details of gVisor sandboxing etc): Safe Ride into the Dangerzone: Reducing Attack Surface with GVisor https://news.ycombinator.com/item?id=41630076 https://news.ycombinator.com/item?id=41630076

prophesi 2y ago
I appreciate this! It would add another attack vector, but I could see the utility in SaaS'ifying this for servers to convert user-uploaded content on-the-fly.
mjevans 2y ago
This looks better than q(ubes)-pdf, but still not ideal. Seems that PyMuPDF is used with a fixed (single pathname) "/tmp/input_file" ? https://github.com/freedomofpress/dangerzone/blob/main/dangerzone/conversion/doc_to_pixels.py#L183 https://github.com/freedomofpress/dangerzone/blob/main/dange... Everything else is tossed through LibreOffice. Meanwhile what I'd prefer for PDFs is some allow-listed set of 'safe' PDF operations (layout image, layout text) to be used with sanitized inputs (no underflows, overflows, corruption, etc), and the results of any at snapshot-runtime code evaluated and then flattened out to a safe element. Image OCR could be run atop that. Similarly it'd be nice if a filter like that existed for the other documents, but as an individual contributor I don't have the human power to keep up with that goal and would take the same low hanging fruit worse but secure output route.
- kccqzy 2y ago
  > allow-listed set of 'safe' PDF operations (layout image That's the problem right there. PDF supports many image formats, including ones that are useful but you may have never heard of like JBIG2 for scanned documents. And the parser for those image formats needed to be secure as well. One very famous exploit is just exploiting JBIG2 (among other things): https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
  - eviks 2y ago
    You could simply not support those obscure image formats?
    - danielheath 2y ago
      And when a journalist receives a tip from a reliable source they can't open with their secure PDF tool, they are more likely to do what? Disregard the info, or open the PDF in an unsafe tool?
    - kccqzy 2y ago
      That's not an option. JBIG2 is objectively the best format for compressing black-and-white scanned images. The Adobe Acrobat software has an "optimize scanned PDF" feature that produces this format. It's not obscure at all.
      - eviks 2y ago
        That objectively best format that was banned in some areas due to replacing important numbers in accounting documents? But if it's the default in Acrobat, yeah, likely not obscure enough
- lima 2y ago
  In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing fundamentally wrong with the approach.

prophesi 2y ago

I appreciate this! It would add another attack vector, but I could see the utility in SaaS'ifying this for servers to convert user-uploaded content on-the-fly.

mjevans 2y ago

This looks better than q(ubes)-pdf, but still not ideal. Seems that PyMuPDF is used with a fixed (single pathname) "/tmp/input_file" ? https://github.com/freedomofpress/dangerzone/blob/main/dangerzone/conversion/doc_to_pixels.py#L183 https://github.com/freedomofpress/dangerzone/blob/main/dange... Everything else is tossed through LibreOffice. Meanwhile what I'd prefer for PDFs is some allow-listed set of 'safe' PDF operations (layout image, layout text) to be used with sanitized inputs (no underflows, overflows, corruption, etc), and the results of any at snapshot-runtime code evaluated and then flattened out to a safe element. Image OCR could be run atop that. Similarly it'd be nice if a filter like that existed for the other documents, but as an individual contributor I don't have the human power to keep up with that goal and would take the same low hanging fruit worse but secure output route.

kccqzy 2y ago
> allow-listed set of 'safe' PDF operations (layout image That's the problem right there. PDF supports many image formats, including ones that are useful but you may have never heard of like JBIG2 for scanned documents. And the parser for those image formats needed to be secure as well. One very famous exploit is just exploiting JBIG2 (among other things): https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
- eviks 2y ago
  You could simply not support those obscure image formats?
  - danielheath 2y ago
    And when a journalist receives a tip from a reliable source they can't open with their secure PDF tool, they are more likely to do what? Disregard the info, or open the PDF in an unsafe tool?
  - kccqzy 2y ago
    That's not an option. JBIG2 is objectively the best format for compressing black-and-white scanned images. The Adobe Acrobat software has an "optimize scanned PDF" feature that produces this format. It's not obscure at all.
    - eviks 2y ago
      That objectively best format that was banned in some areas due to replacing important numbers in accounting documents? But if it's the default in Acrobat, yeah, likely not obscure enough
lima 2y ago
In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing fundamentally wrong with the approach.