I have a PDF with important information that may contain malware. What would be the best way to view it?
Document-based exploits are directed not at the document itself, but rather at some vulnerability in the viewer. If you view the document in a program that isn't vulnerable (or in a configuration that inhibits the vulnerability), then you won't be exploited.
The real issue is knowing whether or not your viewer is vulnerable, which usually means knowing specifically what the exploit is. But there are alternate PDF viewers such as foxit or even Google chrome's built-in viewer that do not necessarily have the same vulnerabilities as Adobe's official viewer. This is not necessarily true for all vulnerabilities, so it's important to understand what you're getting in to ahead of time.
If you find yourself frequently dealing with potentially malicious materials, it would be very wise to set up a hardened virtual environment. I'd recommend booting into a Linux system and running your target OS (usually Windows) in Virtualbox or a similar environment. Save a snapshot of the virtual OS, and then revert to that snapshot after you're done interacting with the malicious content. Also, it's not a bad idea to run the host Linux environment from a read-only installation (i.e. Live-CD).
Put it through a PDF viewer that isn't vulnerable to the exploit. If it's someone else's viewer, that's even safer. Try Google Docs, where they will parse it and display it as HTML, so the malicious payload won't harm you. (I'm sure that their PDF parser is extremely secure, so you shouldn't feel bad about possibly infecting them.)
Use pdf.js with a sandboxed browser (such as Chromium) in a virtual machine without network access.
It should be quite tricky for a malware to get out of this.
In this situation I've always used the Unix/Linux/OSX shell command "strings". On *nix systems, do this:
strings ScaryFile.pdf | less
You can also get "strings" for Windows, as mentioned by Polynomial, below. You can download it here. Runs on XP or higher. Here is an example of using it on Windows:
strings ScaryFile | findstr /i TextToSearchFor
But for the rest of my answer here I'll assume you're on *nix, since that is my experience with strings. Assuming all you're looking for is text content (not bitmaps or vector graphics), you can scroll down or search and find bits of the text you need. Unfortunately, to find it you have to wade through tons of metadata, most of which is in XML, and formatting settings in some other markup, plus some binary (as ascii, not raw bytes). So you may want to use the search capabilities of the "less" command. To search down the document for the case-sensitive string "thingyouwant", use the slash key + your string + return:
Then hit the "n" key to see the next instance of "thingyouwant", over and over till you find what you want. You can use the "?" key to do the same thing in the upward direction. See the less man page (type "man less") for more magic.
You could also analyze things like which URLs the document links to:
strings ScaryFile.pdf| grep -i "http" | sort | uniq | less
But, as stated above, 99% of what you'll see from the output of "strings" is going to be metadata and formatting settings.
Use a virtual machine that can be reverted to clean slate after tests. If the PDF reader is vulnerable, your real workstation will be much less likely to be affected.
Latest versions of Adobe Reader (version 10.1 and up) support "Protected Mode" or sandboxing which can be used to view untrusted PDF files. This effectively restricts the access of the process displaying the PDF file to
%appdata%\Adobe\Acrobat and other PDFs which are explicitly opened by the user.
Protected mode has to be activated by going to Edit->Preferences menu and selecting either General or Security tab, depending on the version:
Obviously, you'll want to close any sensitive PDFs like your bank statements before opening the untrusted one.
Sumatra also has configuration options to lock it down even further, such as preventing file system or internet access.
Common PDF viewers attempt to provide safety for these features by creating sandbox environments or giving the user prompts, but these solutions are both more complex (and therefore subject to their own vulnerabilities) and less compatible with other parties' products than the simpler solution of simply leaving out that functionality entirely.
Sumatra is one example of a PDF viewer that does not provide many of the functions which are most commonly used in PDF exploits. By completely eliminating entire categories of potential attacks, such programs greatly reduce the risk of viewing unknown PDF files.
A further advantage of using a less popular viewer is that because it's both less common and less powerful, it's a less interesting target.
The Sumatra viewer could be possibly be exploited by a specially crafted PDF which takes advantage of some unknown bug to cause a buffer overflow, for example. Such cases are rare however, and there have not been any significant security exploits for Sumatra in recent years.
We can say ALL of the in-the-wild or targetted attack using malicious PDF file are covered with obfuscation techniques to hardened the analysis or detection process.
Another easy and less time consuming option is to open it in the Sandboxie app, which would isolate it.
You can open the PDF in a container. Here's a docker image you can use: https://hub.docker.com/r/chrisdaish/acroread/
MY_PDF_DIR='/tmp/foobar' docker pull chrisdaish/acroread docker run -v $MY_PDF_DIR:/home/acroread/Documents:rw \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -e uid=$(id -u) \ -e gid=$(id -g) \ -e DISPLAY=unix$DISPLAY \ --name acroread \ chrisdaish/acroread
This will open an Acrobat Reader that will display via the local X server.
The approach reduces the attack surface, but not 100% safe as it's got access to your X server.
You can use a less popular viewer/OS combination. I guess no one targets Okular running on FreeBSD (though it can still be vulnerable), so if you open the file in a VM you should be very safe.
In order to do harm the rogue payload must match the viewer version and the OS and the CPU architecture of course. It is really low-level assembly and memory stuff (the payload expects to be placed at a particular memory address and expects some standard system functions to be available). If you change any of those, then the payload may not execute properly (or the viewer may simply crash without doing harm).