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.
Didier Stevens 
[…] 3. A week ago Security Researcher Didier Stevens posted a video on how acrobat reader exploit works without opening the PDF and today he explains how only by having an infected file on your hard disk can be vulnerable and how Windows Indexing Services is the cause. Follow the countermeasures. […]
Pingback by Various # 09 – 103 « Fatma Bazargan’s blog — Monday 9 March 2009 @ 13:30
Interesting research.
I guess this will also work for the combination outlook + Windows Desktop Search?
Interesting spam method…
Comment by pc — Tuesday 10 March 2009 @ 14:31
So to add to this, even uninstalling acrobat reader is not enough. Explorer still has AcroRdIF.dll and AcroRd32.dll loaded. You MUST RESTART your PC.
I uninstalled acrobat and then searched my pc for *.pdf files to see if there was anything suspicious around – I did not find anything, but then got to thinking. And sure enough, after uninstalling acrobat, I can still perform text content searches on pdf documents. Yuck.
If you load up procexp you will see that explorer is indeed still holding these dlls around.
Comment by Nick — Tuesday 10 March 2009 @ 15:17
Outlook stores its data in its own proprietary format (.PST if I remember correctly), it don’t think that PDF attachments stored inside that file would be indexed.
Comment by Didier Stevens — Tuesday 10 March 2009 @ 19:34
Interesting, I’ll try to test this. Of course, if it’s Windows Explorer, you can just restart it (kill the process and start a new one, or logout/logon).
Comment by Didier Stevens — Tuesday 10 March 2009 @ 19:37
I should mention that explorer.exe does not automatically load the IFilter and AcroRd32.dll, and it appears to not load it until you do a find “a word or phrase in the file” type search. However, once that loads it, it appears to stick until you somehow end explorer. So a kill or log on/off seems necessary. With all of the tentacles adobe has into the OS, though, it might just be best to restart and be absolutely safe. Who knows what else is still holding on to something from acrobat reader.
Comment by Nick — Tuesday 10 March 2009 @ 20:00
[…] use a lot of Adobe products. Lightroom, Photoshop, Premiere and Acrobat to name some. So, when blogs started buzzing about an Acrobat vulnerability, they grabbed my attention. And when my distinguished colleague […]
Pingback by Latest Adobe vulnerability — In perspective | TECHLifePost — Wednesday 11 March 2009 @ 11:16
Thanks for the solid info — I linked to you from my article for the TECHLife Post.
Comment by Eric Jacksch — Wednesday 11 March 2009 @ 13:11
[…] your users as soon as you can because this is a nasty one. Users who download a malicious PDF do not need to open it to fall victim to that […]
Pingback by Critical Adobe Reader update - Upgrade NOW! | IT a digital life — Wednesday 11 March 2009 @ 16:17
[…] wurde bekannt, dass unter Windows ein Anwender unter Umständen nicht einmal ein präpariertes Dokument selbst […]
Pingback by Adobe Acrobat Reader 9 Update veröffentlicht! « Joerg´s IT-Tech Blog — Wednesday 11 March 2009 @ 19:15
[…] wurde bekannt, dass unter Windows ein Anwender unter Umständen nicht einmal ein präpariertes Dokument selbst […]
Pingback by Adobe schließt kritische Lücke in Reader und Acrobat | Tiger Eye Books — Thursday 12 March 2009 @ 9:13
“Explorer still has AcroRdIF.dll and AcroRd32.dll loaded. You MUST RESTART your PC.”
Nope. Ctrl-Alt-Del, kill Explorer, start Explorer again. What’s all this rebooting, anyway?
Comment by Kuba — Thursday 12 March 2009 @ 9:54
Kuba, you are correct. That will handle the AcroRdIF.dll and AcroRd32.dll still cached. What other processes still have some part of reader cached? Who knows. You could search to see who still has it loaded, or you could just restart and not worry about it.
Also, another interesting tidbit. There are tips out there about unregistering AcroRdIF.dll and PDFShell.dll. These work great; that is, until acrobat reader detects what you have done and reconfigures itself on next launch (it may not detect this til you next restart windows). At this point, it reregisters the DLLs, and also changes the windows registry so that pdf files will again automatically open when browsed to in internet explorer.
Acrobat Reader is pervasive enough that it should have a “secure” install mode. No shell extensions, no IFilters, no web browser integration, no javascript. Do the one thing people actually want… open PDFs… and do it well without being a severe security liability.
Comment by Nick — Thursday 12 March 2009 @ 16:52
[…] […]
Pingback by Adobe parchea a medias su vulnerabilidad casi un mes después, mientras Foxit Reader lo soluciona en - Foro de Informatica - Foro de Windows 7, Windows Vista y Noticias de informatica — Friday 13 March 2009 @ 11:21
SA AV Vendor Recycling News for FUD Marketing…
ClassicFM just phoned me for comment on this story. I did some quick research and was rather dismayed to find that this appears to be an attempt to drum up some press references for marketing rather than a responsible informing of the public.It was ref…
Trackback by Dominic White — Tuesday 17 March 2009 @ 11:20
[…] Encryption, My Software, RFID — Didier Stevens @ 7:35 OK, after getting side-tracked by /JBIG2Decode PDFs, let’s get back on the smartcard and RFID […]
Pingback by Poken Peek « Didier Stevens — Thursday 26 March 2009 @ 7:35
[…] Stevens schreibt “Look mommy, no hands“, und meint damit, dass er ohne Zutun des Opfers mit einer manipulierten PDF-Datei einen […]
Pingback by ψ² = Ps(i)² » Blog Archive » Wer hat an der Uhr gedreht… — Wednesday 10 June 2009 @ 9:20
[…] use a lot of Adobe products. Lightroom, Photoshop, Premiere and Acrobat to name some. So, when blogs started buzzing about an Acrobat vulnerability, they grabbed my attention. And, when my distinguished colleague […]
Pingback by Adobe vulnerability — In perspective | Eric Jacksch — Thursday 10 June 2010 @ 0:41
hi Didier
Do you think sysinternals autoruns shows these ifilters?
There is an “explorer shell addons”, I am not sure they are ifilters.
Otherwise I will try to write to sysinternals and suggest them to add ifilters.
As usual compliments for the articles.
Best regards, Sala
Comment by Massimo Sala — Thursday 7 March 2019 @ 22:17
Test in a VM with an old version of adobe reader
Comment by Didier Stevens — Thursday 14 March 2019 @ 9:59