PDFs are, in security terms, not great. They’re better than Word documents, Flash files, and Java applets, but not by a whole lot. There’s been at least one exploit which allows a malicious PDF to escape the “sandbox” and attack the computer.
Qubes OS, by comparison, is a “secure by design” OS. Compared to e.g OpenBSD — which aims to take a normal OS structure and get rid of all the security holes — Qubes takes quite complex systems and puts them together in designed-to-be-secure way.
Instead of asking complex systems to be secure, Qubes pins their security on the (much simpler and easier to audit) Xen hypervisor and use it to create virtual air gaps between “secure” and “insecure” virtual machines.
(As it happens, Xen was the victim of the cross-VM side channel attack we saw a few months ago, so this approach isn’t perfect.)
Now, to the PDF problem.
How do you (as a hypothetical Qubes user) take a presumed-compromised PDF and bring it over to a “secure” machine?
Their solution is as elegant as it is paranoid: spawn a new, presumed-insecure VM, and convert the PDF to a straight RGB bitmap. Even if the original PDF manages to infect the “clean” PDF, by having the “secure-side” reader looking only for bitmap data, the worst it might get is a garbled image.
Lifehacking, herbs: Garlic is as strong as it is awesome. Following it with some sliced ginger on bread or raw cloves (dissolved in the mouth over half an hour) seems to improve energy levels. Presumably ginger and cloves help quell a bit of upset from the stomach digesting lots of garlic.
Lifehacking, soft stuff: In all this experimentation and design, what actually matters is happiness. While trying to achieve this directly through e.g chemical means is notorious for having poor results, it’s still worth keeping in mind.
” Arguably one of the biggest challenges for desktop security is how to handle those overly complex PDFs, DOCs, and similar files, that are so often exchanged by people, or downloaded from the Web, and that often provide a way for the attacker to compromise the user’s desktop system.
Today I would like to discuss a recent innovation we created for Qubes OS that allows to securely convert those pesky PDFs (as well as essentially any graphics files) into trusted PDFs. Here by a “trusted PDF” I mean a file that should be harmless to the user’s system, so, a non-malicious PDF.[…]
Ok, so what’s the simplest possible representation of an arbitrary PDF file? Yes, it’s the RGB format, which is essentially just a raw array of RGB values for each pixel. In fact, I’m not sure there could be anything simpler in the Known Universe to represent a PDF file…[…]
The obvious disadvantage of converting a PDF to an RGB representation is that one looses text search, as well as copy and edit capabilities (e.g. in case of PDF forms). So, converting Intel’s IA32 Software Developer’s Manual this way would certainly not be a good idea… But, hey, such large PDFs can always be opened in a Disposable VM – they would be fully functional then, only that you would need to wait a few seconds for the PDF window to pop up. Or, better yet, why not keep all such PDFs in a dedicated domain? E.g. I have a VM called “work-pub” where I keep tons of various, publicly available PDFs, such as the mentioned Intel’s SDM, as well as various chipset docs, conferences papers and slides, and generally lots of stuff. The key point is that all in this VM is public material (and also all is related to my work), so that I don’t really care if any of those PDFs compromises my work-pub domain. In the worst case, I will revert the VM from backup and download any missing PDFs again from the web. They are public after all. […]
Being able to right-click on a PDF file and have it converted into a trusted PDF is one thing. Having this mechanism adopted by users and actually making their daily computing safer, is another story.
Users will likely have hundreds of PDF spread over their home directories, and the real challenge is how to make sure that the user never accidentally opens the unconverted, untrusted PDF. We can think of several approaches to this problem:
We modify the Thunderbird, Firefox, etc, e.g. by providing specific plugins, to always perform PDF conversion on each file that we got via email or downloaded from the Web. Additionally we convert all the already present PDFs in the user’s home directory (file system?). And, additionally, we modify Qubes file copy operation to also always do automatic PDF conversion whenever one transfers files from other domains (if Qubes qrexec policy allows for such transfer in the first place, of course).
This approach would not be optimal, because some PDFs, as we discussed above, might not be well suited for conversion-through-bitmap process – they might be large PDFs where text search is crucial, some conference papers for review, where text copy is crucial, or some editable forms. That’s why it seems better to take a slightly different approach:
We modify mime handlers for PDF files (as well as any other files that our converter supports) and then upon every opening of the file (e.g. via mouse click in a file manager) our program gets to run and its job is to determine whether the file should be opened natively, converted to a trusted PDF, or perhaps opened in a Disposable VM. Of course, upon “first” opening we should probably ask the user about the decision, if this cannot be determined automatically. E.g. if we can reliably determine the file is already converted, we can safely open it without prompting the user, but if it’s not, we should ask – perhaps the user would like to open it in a Disposable VM instead of converting, or perhaps the file should be considered trusted anyway, because it was created by the user herself.
This second approach seems like a way to go, and we will likely implement it sooner or later (probably sooner, but after the upcoming R2 Beta2). It should also be noted, that typically user would need such mechanism only in some domains – e.g. I really feel the need for such protection in my “work” domain, but not in any other. But that, of course, depends on how one partitions their digital life into security domains.”