8 ms·
Dangerzone: Convert potentially dangerous PDFs, documents, or images to safe PDF
- rtpg 7y agoThis is definitely a good brute force strategy I ... think there’s another technique that relies a bit on trusting the printing drivers to do the right thing, where you can tell Ghostscript to print your document, and target another PDF. This should at least remove interactive components in a PDF
- userbinator 7y agoIt's definitely brute force, in that it's the equivalent of printing a document onto paper and then scanning it back in. This "flattening" is highly effective at sanitising, but also removes all the semantic content in the process; the output should be several times larger than the input (and if it isn't, then it's an indication that something very suspicious was in the input....)
- necovek 7y agoIndeed, I was hoping for something smarter, that would remove only the "risky" bits of PDF, but keep the overall structure (and size).
- heartbeats 7y agoWhat about converting PDF to PostScript and back? It should keep most of the semantic information while removing the exploits.
- necovek 7y agoYeah, perhaps. The "gruntwork" would be to figure out if that is sufficient. Heck, taking your idea further, perhaps convert to something non-derivative like HP's PCL5 and back. Or SVG or...
- est31 7y agoIIRC this is also how Firefox is doing it for its pdf.js print feature: https://github.com/mozilla/pdf.js/blob/master/web/pdf_print_service.js https://github.com/mozilla/pdf.js/blob/master/web/pdf_print_... Which is why when you print a PDF from Firefox, it doesn't look very nice. But it's safer than sending unsanitized PDFs to printers.
- HeavenFox 7y agoI used to deal with PDF at my day job. Among all the tools we use in production, Ghostscript probably has the most 0 day. Thankfully we're paranoid about security and run everything in sandbox. Still it's no fun getting nagged by security to upgrade our Ghostscript version.
- cjbprime 7y agoIt's funny how they all seem to have been found by one person (Tavis Ormandy) too. It's like the setup and PostScript standard are so baroque that only one human understands them, and that human takes a week or so every year or two to research and drop another 0day. https://bugs.chromium.org/p/project-zero/issues/detail?id=1640 https://bugs.chromium.org/p/project-zero/issues/detail?id=16...
- deleted 7y ago[deleted]
- ageitgey 7y agoHonestly it is starting to feel like most major exploits in most major software/platforms are being found by Tavis Ormandy these days. He's really good at what he does.
- NKCSS 7y agoWell, Tavis is one of the infosec superstars, the amount of stuff he comes up with is amazing.
- tptacek 7y agoBe very wary of exposing Ghostscript to untrusted data.
- namanyayg 7y agoUseful tool -- it's trivial to make a RAT bypass chat/email .doc/.PDF attachments. I don't open any files on my PC from people I don't personally know -- use webviewers.
- A4ET8a8uTh0 7y agoOdd question. Why would a webviewer be safer in this case? edit: Thank you for both answers. I thought it had to do with sandbox rationale, but couldn't mentally get past the fact that sandbox could potentially be escaped too. Eh, I think it is time for sleep.
- mettamage 7y agoWell is it safe? Don't know. Safer: definitely. Given that the collective amount of PDF attacks is some number, now this particular PDF needs to attack PDF and the webviewer. Assuming that 1% of all PDFs do that, I'd say it's 100 times safer than not using a webviewer. If you still think that 1% of all potential PDF attacks is too unsafe, then that's a different discussion. If you think my 1% is off, then that's a different discussion too. All I'm saying is that it's safer.
- saagarjha 7y agoWell, PDF attacks need to attack the viewer you're using too…
- mettamage 7y agoTrue, but in most cases this is assumed to be a popular PDF reader. If it is specifically targeting a webviewer, I agree. But that still means that there is some JS PDF parser in between, though that provides very little in terms of security, I doubt that such a parser will check for malicious input.
- heeen2 7y agoAfaik chromium uses the same pdf renderer as foxit (pdfium)
- rurban 7y agoGood, but I don't think the change from running the sandbox in a VM (in Qubes case even Xen, not kvm) to docker is an improvement. Escaping docker is much easier than Xen.
- TekMol 7y agoDownload Dangerzone So instead of opening a PDF from the internet on my machine, I now run code from the internet on my machine?
- seanhunter 7y agoThere's a big difference between opening a random PDF and downloading code which you can view yourself on github, no? Or does your computer (from cpu microcode up) only run code which you have personally written and is not "from the internet"?
- techybuddha 7y agoYou have not yet downloaded “HighwayToTheDangerzone”. You are still ok.
- Stierlitz 7y agoAll because Microsoft, the company that made formated text dangerous.
- toxicFork 7y agoWhen one enables functionality, this results in both good and bad behaviour. Microsoft did not build the guns, it made engineering possible. Some engineers are bad. But a lot are good.
- badrabbit 7y agoVery nice but fyi: most malicious pdf just contains links to something else,usually shortlinks. Social engineering is hard to mitigate.
- seanhunter 7y agoIf I understand this correctly, a link wouldn't survive this as the pdf is turned into images and then those images back into a pdf. So it's essentially like a scan of very high quality. What you would end up with is an image that looks like a link but would not be clickable.
- badrabbit 7y agoDoesn't matter if it is not clickable. There are existing phishing campaigns that use jpeg attachments asking the user to copy paste it (or just let the user try to copy and fail and manually type it out). Perhaps adding a text warning users to not open any links on the document will easily prevent that?
- leskat 7y ago> Dangerzone can optionally OCR the safe PDFs it creates, so it will have a text layer again I'm not completely sure, but wouldn't this parse links and make them accessible again, possibly even clickable?
- edoceo 7y agoMaybe use pdftotext wrapper to extract text along side the image based pdf.
- clort 7y agoA links displayed text and its destination URL are not necessarily the same. Rendering the document to a bitmap then OCRing that would get the display text rather than the URL. I would think that it would be normal for a malicious URL to be obscured with an innocent looking display text.
- seanhunter 7y ago
- yeleced98 7y agogreat project you guys should also check this one out : https://github.com/sh-dv/hat.sh https://github.com/sh-dv/hat.sh
- johnlorentzson 7y agoThis kind of makes me wonder why PDFs can even act maliciously in the first place. Why does it have the ability to do these things?
- MaxBarraclough 7y agoI think it's just that Adobe wanted to add more features, even ones that have no place in the PDF format.
- masklinn 7y agoPDF derives from PostScript which is a full-blown programming language so it's an "original sin" either way. Then over time Adobe added a number of interactive (forms), multimedia and rich media (embedded JS) features, leading to even more vectors.
- maxerickson 7y agoBecause computer, a benign feature of pdf can still lead to an exploit in a viewer. Note the attempts at the link to sanitize image formats that don't have over the top complexity. If your question is why an electronic document format has support for images and interactivity, I don't know what to tell you.
- zuckluni 7y agoObligatory humblebrag/shameless plug for my open source PDF(+ other docs) to Image converter, which runs as a web app. It's self hosted open source (but easiest to run on FreeBSD). Uses Ghostscript/OpenOffice under the hood: https://github.com/dosyago/p2..git https://github.com/dosyago/p2..git
- manthideaal 7y agoIn (1) the author use as a cv a pdf that is also a bootloader , and in the comments it seems that he has improved the code. I wonder if he could render dangerzone as futile. (1) https://news.ycombinator.com/item?id=19344146 https://news.ycombinator.com/item?id=19344146 Edited: Added in the comments of that post there is a reference to pocorgtfo16.pdf: is valid as a PDF document, a ZIP archive, and a Bash script that runs a Python webserver which hosts Kaitai Struct’s WebIDE which, allows you to view the file’s own annotated bytes. The zip archive has further resources to insane reversing deep dives, code to study and more. [2] https://www.alchemistowl.org/pocorgtfo/:w https://www.alchemistowl.org/pocorgtfo/:w
- ris 7y agoIt's nice that PDF security is getting a bit more attention, but there are a number of things that this approach will trash, for instance, I don't have high hopes for the accessibility of the resulting PDF. (edit: and needless to say, any software in your pipeline which does full interpretation of an untrusted file will itself become the target for attacks, so this is only a useful tool if it is run in an extremely restricted environment) I for one have been looking a lot into PDF/A for security. PDF/A is really meant for archival, but as a side effect has disallowed an awful lot of weird PDF features which are a security nightmare and pdf readers tend to implement badly/buggily. PDF/A-1 for example, the strictest level, disallows JPEG2000, TIFF, JavaScript, PostScript, embedded files... (PDF/A-3, FWIW is essentially useless from this angle, because they decided to allow arbitrary embedded files, so a valid PDF/A-3 could have pretty much anything in it). There now exists a good PDF/A validator (https://verapdf.org/ https://verapdf.org/) which can be used to ensure PDFs conform to the standard, but of course, won't fix them if they're not. PDF/A has an interesting implementation detail however - compliant PDF readers are supposed to automatically "turn off" non-PDF/A features when they encounter a PDF which declares itself as a particular PDF/A variant (even if it then goes on to attempt to use non-compliant features), which would hopefully prevent dangerous sections from being decoded and avoid exploitation). Another interesting feature of PDF is its appendable nature, which might raise the possibility of being able to "declare" an arbitrary PDF as PDF/A by simply appending an extra section to it, hopefully rendering it less harmful (though possibly at the expense of it appearing to have missing content when rendered).
- heartbeats 7y agoCouldn't you just use a whitelist for the features? If the reader can open a PDF/A-1 file and ignore the bad parts, can't it open a PDF file as PDF/A-1 and remove the bad parts, before saving it again? Then you could use the "re-rendering" technique to extract images: 1. Create a stripped PDF/A-1 file from the original PDF. 2. In a VM, render the two PDF files to two high-resolution image sets. 3. Use some CV algorithm to find the differences. For example, gaussian blur, subtract, threshold, find islands. 4. Use this to come up with areas which use complicated PDF features and/or images. Say this returns that there is an image on page 9 in the rectangle ((17, 338), (400, 300)). 5. Crop out page 9 in rectangle ((17, 338), (400, 300)) from the original PDF. Use some CV algorithm to detect the DPI and whether it's best to encode as JPEG or PNG. Encode it and add to list of images. 6. Add sanitized images back from list, mark PDF/A-1 file with images as PDF/A-2. Of course, you could do this for links or whatever as well. Spit out a list of rectangles and link targets in the PDF, and then put them back in.
- maxfan8 7y agoThis is similar to how QubesOS converts “untrusted PDFs” in a disposable VM. Quite nifty, particularly if you use OCR afterwards. See: https://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html https://theinvisiblethings.blogspot.com/2013/02/converting-u...
- badrabbit 7y agoThis wouldn't work for businesses because PDF forms and legitimate links and even embedded objects. I think this is a great idea if you have users preview the image version before opening the whole thing maybe? Even as an individual, I have had to fill out pdf forms for various usgov applications, job applications,etc...