Sometimes a piece of malware can execute without even opening the file. As this is the case with the /JBIG2Decode vulnerability in PDF documents, I took the time to produce a short video showing 3 ways the vulnerability can trigger without even opening the PDF document.

The first 2 demos use a “classic” /JBIG2Decode PDF exploit, the third demo uses a new PoC /JBIG2Decode PDF exploit I developed. This PDF document has a malformed /JBIG2Decode stream object in the metadata instead of the page. All PDF documents used have just a malformed /JBIG2Decode stream object, they don’t include a payload (shellcode), neither a JavaScript heap spray.

So how is it possible to exploit this vulnerability in a PDF document without having the user open this document? The answer lies in Windows Explorer Shell Extensions. Have you noticed that when you install a program like WinZip, an entry is added to the right-click menu to help you compress and extract files? This is done with a special program (a shell extension) installed by the WinZIp setup program.

When you install Adobe Acrobat Reader, a Column Handler Shell Extension is installed. A column handler is a special program (a COM object) that will provide Windows Explorer with additional data to display (in extra columns) for the file types the column handler supports. The PDF column handler adds a few extra columns, like the Title. When a PDF document is listed in a Windows Explorer windows, the PDF column handler shell extension will be called by Windows Explorer when it needs the additional column info. The PDF column handler will read the PDF document to extract the necessary info, like the Title, Author, …

This explains how the PDF vulnerability can be exploited without you opening the PDF document. Under the right circumstances, a Windows Explorer Shell Extension will read the PDF document to provide extra information, and in doing so, it will execute the buggy code and trigger the vulnerability. Just like it would when you would explicitly open the document. In fact, we could say that the document is opened implictly, because of your actions with Windows Explorer.

So let me demo 3 circumstances under which a PDF Shell Extension will act and thereby trigger the vulnerability. One important detail before I do this: when the exception occurs in the Adobe Acrobat code, it is trapped by Windows Explorer without any alert. That’s why in the demos, I attached a debugger (ODBG) to Windows Explorer to intercept and visualize this exception. So each time the vulnerability triggers, the view switches to the debugger to display the exception.

In the first demo, I just select the PDF document with one click. This is enough to exploit the vulnerability, because the PDF document is implicitly read to gather extra information.

In the second demo, I change the view to Thumbnails view. In a thumbnail view, the first page of a PDF document is rendered to be displayed in a thumbnail. Rendering the first page implies reading the PDF document, and hence triggering the vulnerability.

In the third demo, I use my special PDF document with the malformed stream object in the metadata. When I hover with the mouse cursor over the document (I don’t click), a tooltip will appear with the file properties and metadata. But with my specially crafted PDF document, the vulnerability is triggered because the metadata is read to display the tooltip…

So be very careful when you handle malicious files. You could execute it inadvertently, even without double-clicking the file. That’s why I always change the extension of malware (trojan.exe becomes trojan.exe.virus) and handle them in an isolated virus lab. Outside of that lab, I encrypt the malware.

YouTube, Vimeo and hires Xvid.

Quickpost info