JBIG2Decode Adobe PDF Vulnerability now Completely Hands Free
Adobe's expected patch for the JBIG2Decode exploitable vulnerability is expected in just a few days time. However, as the wider security community gets to spend more time playing around with the vulnerability, more interesting ways to trigger the vulnerability are found.
After his recent documentation of three methods to trigger the vulnerability without actually double clicking and opening an affected file, Didier Stevens has gone one better and has documented a new exploitation method that activates the exploit with no user interaction, and which results in the exploit code running with Local System privileges.
In order for a system to be vulnerable to this particular approach, it needs to have Acrobat Reader 9.0 installed, and the Windows Indexing Services started. As part of the installation process for Reader 9.0, it installs an assistant (IFilter) to allow Windows Explorer to interpret and index PDFs. This is called by Windows Explorer when it encounters a PDF and it subsequently calls the Acrobat Reader core interpreter, which is vulnerable to the JBIG2Decode vulnerability.
In Specific technical terms, cidaemon.exe encounters a PDF and calls AcroRDIF.dll, which loads AcroRD32.dll, which is vulnerable to the exploit. This all takes place with Local System privileges.
A positive aspect to the discovery is that the Indexing Service is not activated by default on Windows XP SP2, though it will be activated if the user answers yes to the offer to make future searches faster after they first carry out a local search in an administrator level account. The counter to this is that other software can also call the Acrobat IFilter, including Windows Desktop Search (also vulnerable, but to a lesser privileged Local Service account), SharePoint and SQL Server (which has interesting implications for DBAs and developers who elect to store binary data in their databases).
Didier describes a blended attack where a system that has had the Indexing Service enabled, and also has a means to upload files can be remotely compromised to give a local system shell with absolutely no interaction from a local or logged in user.
There is some lingering doubt as to when the affected dlls are loaded by Windows Explorer, but it is guaranteed that once the user has tried to carry out a "word or phrase in the file" type search, the dlls are loaded and present until the next time Windows Explorer is restarted. Even with the options of just killing and restarting the process, or just logging the active user off and back on, it isn't obvious at this stage just how likely it is that the affected dlls have been properly unloaded from memory. A full system shut down and restart is about the only guaranteed way to make sure.
It has also been found by commenters to Didier's blog that even uninstalling Acrobat Reader leaves behind the vulnerable dlls that hook into Windows Explorer, something that can be simply verified by looking for them in the Process Explorer after attempting "a word or phrase in the file" type search after uninstalling Reader.
Depending on how alternative desktop search solutions (such as Google Desktop Search [doesn't use IFilters unless third party add on has been included], Yahoo! Desktop Search, and a number of commercial solutions) implement search within a file options, they could also be vulnerable to this particular exploitation method. Similarly, indexing of attachments within PST files could present an exploitable problem when the right conditions are encountered.
11 March 2009
Social bookmark this page at eKstreme.
Alternatively, Bookmark or Share via AddThis
Do you like how we cover Information Security news? How about checking out our company services, delivered the same way our news is.
Let our Free OS X Screen Saver deliver the latest security alerts and commentary to your desktop when you're not at your system.
Comments will soon be available for registered users.
Subscribe to our feed.