Is there some reason why just viewing the PDF with a FLOSS, limited PDF viewer (e.g. atril) would not accomplish the same level of safety? What can a "dangerous PDF" do inside atril?
Convert potentially dangerous PDFs to safe PDFs
21–30 of 72 posts
Re: Convert potentially dangerous PDFs to safe PDFs
#22A handy side use for this is compressing PDFs.
For some reason, printing 1 page of an Excel or Word document to a PDF often gets up to around 4MB in size. Passing it through this compresses it quite well.
Just ran a quick test:
- 1-page Excel PDF export: 3.7MB
- Processing with Dangerzone (OCR enabled): 131KB
Re: Convert potentially dangerous PDFs to safe PDFs
#23Earlier quoted context omitted.
Do you have any specifics on what Drive does? Any examples of it fixing embedded virii? Or is this blind assumption?
I assume they mean "upload to drive and use the web based reader to view the PDF," not "upload to drive and download it again"
And what special sauce does the web preview use? At some point, someone has to actually parse and process the data. I feel like on a tech site like Hacker News, speculating that Google has somehow done a perfect job of preventing malicious PDFs beckons the question: how do you actually do that and prove that it's safe? And is that even possible in perpetuity?
Re: Convert potentially dangerous PDFs to safe PDFs
#24Is there some reason why just viewing the PDF with a FLOSS, limited PDF viewer (e.g. atril) would not accomplish the same level of safety? What can a "dangerous PDF" do inside atril?
It looks like atril is mostly written in C:
https://github.com/mate-desktop/atril
A crafted PDF can potentially exploit a bug in atril to compromise the recipient's computer since writing memory-safe C is difficult. This approach was famously used by a malware vendor to exploit iMessage through a compressed image format that's part of the PDF standard:
https://projectzero.google/2021/12/a-deep-dive-into-nso-zero...
Re: Convert potentially dangerous PDFs to safe PDFs
#25I personally just upload them to google drive. It would be a serious pwn if they could somehow still do a compromise through google drive.
Does google drive apply any transformation over the PDF, or are you effectively loading the same document in your browser on the round trip?
They have some kind of virus scanner for files you open via a share link. Not sure about the ones you have stored on your own drive unshared.
But probably the main security here is just using the chrome pdf viewer instead of the adobe one. Which you can do without google drive. The browser PDF viewers ignore all the strange and risky parts of the PDF spec that would likely be exploited.
Re: Convert potentially dangerous PDFs to safe PDFs
#26Heh, I've seen this a bunch of times and it's of interest to me, but honestly? It's sooooo limiting by being an interface without a complementary command line tool. Like, I'd like to put this into some workflows but it doesn't really make sense to without using something like pyautogui. But maybe I'm missing something hidden in the documentation.
https://github.com/freedomofpress/dangerzone/blob/main/dange...
How hard did you look the other times?
Re: Convert potentially dangerous PDFs to safe PDFs
#27Earlier quoted context omitted.
This doesn't seem to be designed for leakers, i.e. people sending PDF's -- it's specifically for people receiving untrusted files, i.e. journalists. And specifically about them not being hacked by malicious code . I'm not seeing anything that suggests it's about trying to remove traces of a file's origin. I don't see why it would need a warning for something it's not designed for at all.
It would be natural for a leaker to assume that the PDF contains something "extra" and to try and and remove it with this method. It may not occur to them that this something extra could be part of the content they are going to get back.
From the tool description linked:
> Dangerzone works like this: You give it a document that you don't know if you can trust (for example, an email attachment). Inside of a sandbox, Dangerzone converts the document to a PDF (if it isn't already one), and then converts the PDF into raw pixel data: a huge list of RGB color values for each page. Then, outside of the sandbox, Dangerzone takes this pixel data and converts it back into a PDF.
With this in mind, Dangerzone wouldn't even remove conventional watermarks (that inlay small amounts of text on the image).
I think the "freedomofpress" GitHub repo primed you to think about protecting someone leaking to journalists, but really it's designed to keep journalists (and other security-minded folk) safe from untrusted attachments.
The official website -- https://dangerzone.rocks/ -- is a lot more clear about exactly what the tool does. It removes malware, removes network requests, supports various filetypes, and is open source.
Their about page ( https://dangerzone.rocks/about/ ) shows common use cases for journalists and others.
Re: Convert potentially dangerous PDFs to safe PDFs
#28Is there some reason why just viewing the PDF with a FLOSS, limited PDF viewer (e.g. atril) would not accomplish the same level of safety? What can a "dangerous PDF" do inside atril?
It looks like atril is mostly written in C: https://github.com/mate-desktop/atril A crafted PDF can potentially exploit a bug in atril to compromise the recipient's computer since writing memory-safe C is difficult. This approach was famously used by a malware vendor to exploit iMessage through a compressed image format that's part of the PDF standard: https://projectzero.google/2021/12/a-deep-dive-into-nso-zero...
This is why Firefox chose to implement a custom PDF reader in pure JS for better sandboxing leveraging the existing browser JS sandboxing.
As a side effect, it's been a helpful JS library for embedding PDFs on websites.
The Chrome PDF parser, originating from Foxit (now open-sourced as PDFium), has been the source of many exploits in Chrome itself over the years.
Re: Convert potentially dangerous PDFs to safe PDFs
#29Heh, I've seen this a bunch of times and it's of interest to me, but honestly? It's sooooo limiting by being an interface without a complementary command line tool. Like, I'd like to put this into some workflows but it doesn't really make sense to without using something like pyautogui. But maybe I'm missing something hidden in the documentation.
https://github.com/freedomofpress/dangerzone/blob/main/dange... How hard did you look the other times?
Not much further than their documentation, friend! But thanks for finding that, that's actually super helpful! I hope somebody puts in a pr for updating the documentation to make it clear what functionality their tool has.
Re: Convert potentially dangerous PDFs to safe PDFs
#30I personally just upload them to google drive. It would be a serious pwn if they could somehow still do a compromise through google drive.
Does google drive apply any transformation over the PDF, or are you effectively loading the same document in your browser on the round trip?
I often view PDFs in Drive, and it's definitely not just displaying the document with the native web browser. It is rendered with their "Drive renderer", whatever that is. They don't even display a simple .txt file natively in the browser.