Didier Stevens

My previous blogpost showed how minimal user interaction can still get a malicious PDF document to infect a machine. Remembering F-Secure’s misadventure with .WMF and Google Desktop Search, I took some time to look at Windows Indexing Service. The news is not good. This time, I can get a PoC PDF document to trigger the /JBIG2Decode bug without any user interaction whatsoever. And the bug happens in a process running with Local System rights!

On a Windows XP SP2 machine with Windows Indexing Services started and Adobe Acrobat Reader 9.0 installed, there is absolutely no user interaction required to trigger the /JBIG2Decode vulnerability. When the PoC PDF file is on the disk, it will be indexed by Windows Indexing Services and the buggy /JBIG2Decode code will be executed.

When Adobe Acrobat Reader 9.0 is installed, it also installs an IFilter (AcroRdIF.dll). This COM object extends the Windows Indexing Service with the capability to read and index PDF documents. When the Windows Indexing Service encounters a PDF file, it will index it. The content indexing daemon (cidaemon.exe) calls the Acrobat IFilter (AcroRdIF.dll) which loads the Acrobat PDF parser (AcroRD32.dll). If the PDF document contains a malformed /JBIG2Decode stream object, it will result in an access violation in the instruction at 0x01A7D89A.

In other words, if you’ve a malicious PDF document on a machine with Windows Indexing Services, it can infect your machine. And you don’t need a user to open or select the PDF document.

The good news is that Windows Indexing Services is not started on a default Windows XP SP2 install. Update: Although Windows Indexing Services is not on by default, after you’ve executed a search as local admin, you’ll be asked if you want “to make future searches faster”. If you answer yes, Windows Indexing Services will be automatically started.
The bad news is that Windows Indexing Services runs under the local system account on Windows XP SP2. This results in a privilege escalation.

Consider a Windows machine with Windows Indexing Services running, Adobe Acrobat reader installed and a file sharing service (FTP/IIS/P2P/…). Uploading a specially crafted PDF document to this machine will give you a local system shell.

To disable Windows Indexing Services’ capability to index PDF documents, unregister the IFilter: regsvr32 /u AcroRdIf.dll

But IFilters are also used by other software:

• Microsoft Search Server 2008
• Windows Desktop Search
• SharePoint
• SQL Server (full-text search)

My PoC PDF file also triggers in /JBIG2Decode in Windows Desktop Search (I tested version 4.0). But Windows Desktop Search has a better security architecture than Windows Indexing Service. Although the service runs under the Local System account, the actual calling of the IFilters is done in a separate process that runs under the Local Service account (this account has less privileges and can’t take full control of the machine).

I’ve not analyzed other applications using IFilters. If you use ScarePoint (that’s how my wife, who has to work with it, calls it) or another IFilter supporting application and you want to be safe, unregister the Acrobat IFilter.

And don’t forget that, depending on  your Windows version and CPU, you’re also protected by technologies like DEP and ASLR.

Google Desktop Search doesn’t use IFilters, unless you’ve installed this plugin to add IFilter support to Google Desktop Search.

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