Slashdot Mirror

I did not know it was possible to detect javascript in a PDF, and I think this is possibly a better approach than a full rewrite (btw: I found this python script: http://blog.didierstevens.com/programs/pdf-tools/ ) So instead of rewriting every PDF, you just choose to delete any PDF attachments that are detected with JavaScript. I assume this will then not break any legitimate PDFs that have comments or forms, etc? It will need testing, I guess.

The mail relay can then be configured to detect and delete any javascript-containing PDFs and allow everything else through (including encrypted, which is more likely to be legit than not). Once again, this is not the only protection against this malicious code, but just one facet. I found some recent exploits that don't need javascript at all, so it seems the safest, yet most likely to make you hated, approach is to rewrite the PDF completely or not allow PDFs at all.

In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."

Just to point out that on Windows, it is actually more secure to use reader x. The sandbox and exploit mitigation techniques are much better than the negligible gain in security by obscurity in using foxit or sumatra.

It took me a while to figure out what you meant. Foxit didn't used to support javascript at all, and that meant that its added security was more than just security through obscurity. It was actually more secure, because all the exploits for AR were based on javascript, which foxit didn't implement. I hadn't realized that foxit later added javascript support. At this point it looks like foxit is roughly equivalent to AR in terms of security: both have js turned on by default, and both allow you to turn it off. ( http://blog.didierstevens.com/2009/05/06/a-very-brief-history-of-foxit-reader-and-javascript/ ) The only possible difference would be whether Adobe or Foxit is more competent in implementing js securely, and that's going to be relatively hard to know, since both are closed source.

Vista/Win 7 does allow you programs to be executed with Low Integrity Level so that it is essentially sandboxed. However, apps have to be written to take advantage of this functionality otherwise there's a good chance they'll break if run with a Low Integrity Level. Some specific PDF Reader-related info here

Well said. Also don't forget that Evince, the default pdf viewer in Gnome and in Ubuntu, is immune to this exploit, as confirmed by several comments on Didier Stevens' original announcement.

So here we have another good reason not to use Acrobat Reader on Linux (or on anything else, for that matter), but also not to trust closed-source alternatives like FoxIt. Evince is fast, efficient, easy to use, has all the necessary features, nothing more, nothing less. And hey, there's even a Windows version!

At least according to Didier:
http://blog.didierstevens.com/2010/04/06/update-escape-from-pdf/

A little better than the crummy cnet write-up. http://blog.didierstevens.com/

I just tested it using 64-bit PDF X-Change Viewer V2.0 Build 44 on Windows 7 and it did not execute the payload. Others on the source blog are reporting that they get a warning but even saying "Yes" fails to open the payload. So it seems that PDF X-Change Viewer is not vulnerable to this exploit.

Then you missed what his exploit is. See http://blog.didierstevens.com/2010/03/29/escape-from-pdf/ but the short of it is that action launch is *not* supposed to allow execution of embedded code. The "POC" PDF he has posted just implements the launch action and only demonstrates that a particular PDF reader supports the launch action.

From a black hat perspective there's a huge difference between executing code on your system and executing arbitrary code.

Further, Adobe Reader displays a scary warning and appears intended to include the name of the application that will be executed, but instead can be caused to display an arbitrary message.

This is abuse of the launch action to get unintended results -- without exploiting a flaw in a particular reader, but (apparently) one implied by the specification itself.

see http://blog.didierstevens.com/2010/03/29/escape-from-pdf/ for more information and screenshots

http://blog.didierstevens.com/2010/03/31/escape-from-foxit-reader/

He got it working in Foxit pretty quickly after the first post about the PoC.

Explaination

Video

Demo PDF file (as .zip)

PDF apparently has (stupidly) a capability to launch an executable program which is run when the PDF file is opened. There's a warning message. All the exploit does is put in some text like "To view the encrypted message in this PDF document, select "Do not show this message again" and click the Open button." into the warning dialog box.

Incidentally, SumatraPDF doesn't do this, but that seems to be a bug; the test file produces "Synchronization file cannot be opened".

Explaination

Video

Demo PDF file (as .zip)

PDF apparently has (stupidly) a capability to launch an executable program which is run when the PDF file is opened. There's a warning message. All the exploit does is put in some text like "To view the encrypted message in this PDF document, select "Do not show this message again" and click the Open button." into the warning dialog box.

Incidentally, SumatraPDF doesn't do this, but that seems to be a bug; the test file produces "Synchronization file cannot be opened".

Explaination

Video

Demo PDF file (as .zip)

PDF apparently has (stupidly) a capability to launch an executable program which is run when the PDF file is opened. There's a warning message. All the exploit does is put in some text like "To view the encrypted message in this PDF document, select "Do not show this message again" and click the Open button." into the warning dialog box.

Incidentally, SumatraPDF doesn't do this, but that seems to be a bug; the test file produces "Synchronization file cannot be opened".

Go to the options menu and turn off javascript. Problem solved.

*Sigh* This isn't true. Some versions of the exploit used Javascript for the heap spray, but Javascript isn't required at all to exploit this issue.

Wow, in that case I guess I'll just remove the association between pdf and any reader in my browser. Most web pdfs can be viewed as a pdf through search engines, anyway.

I meant as an html, but now that I think of it that may be insufficient as well. I guess I'll relegate pdf readers to inside of a VM from now on.

Go to the options menu and turn off javascript. Problem solved.

*Sigh* This isn't true. Some versions of the exploit used Javascript for the heap spray, but Javascript isn't required at all to exploit this issue.

Wow, in that case I guess I'll just remove the association between pdf and any reader in my browser. Most web pdfs can be viewed as a pdf through search engines, anyway.

Go to the options menu and turn off javascript. Problem solved.

*Sigh* This isn't true. Some versions of the exploit used Javascript for the heap spray, but Javascript isn't required at all to exploit this issue.

TFA's author suggests:

This is probably the easiest way: Nirsoft has a Shell Extension manager
  http://www.nirsoft.net/utils/shexview.html

Search for the PDF Shell Extension and disable it.

The Adobe advisory indicates that it affects all platforms, and others in this thread have also pointed it out (some with links).

The second link in the summary also explains that the preview functionality is added through a shell extension installed by Adobe, as opposed to default Windows functionality, although obviously Windows provides the API to make it possible. Similar functionality exists in the Linux and OSX worlds.

This is not the fault of bad Windows design. This is the fault of unnecessary preview functionality available on all systems (and not written by Microsoft), combined with yet another bloody buffer overflow (also not written by Microsoft).

Not correct.

As to JavaScript, itâ(TM)s possible to exploit the /JBIG2Decode vulnerability without using JavaScript, and there are samples of this found in the wild.

—here.

Problem is most people can't make those assertions.
Furthermore, it quite possible that 'respected' sites are serving malware without even knowing it.
So what happens if a respected site, is serving drive-by-download ads from google adsense?