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.
Didier Stevens 
DS, Quick question, how many AVs on virus total detected these 3 pdfs properly
Comment by N — Wednesday 4 March 2009 @ 19:10
This morning, the 2 PDF documents are detected by 2 AVs on VT (ClamAV and Microsoft). But as I said in a previous blogpost, I don’t consider this an issue, as my PoC document just contain a malformed stream, and no payload or heap spray.
Comment by Didier Stevens — Thursday 5 March 2009 @ 7:12
I forgot to add that I did my tests with Adobe Acrobat Reader 9.0 on a fully patched Windows XP SP2 box.
Comment by Didier Stevens — Thursday 5 March 2009 @ 7:24
Will selecting a file using the standard windows open file dialogue (say with Foxit) also trigger this behaviour or is it limited to windows explorer?
Comment by bgc — Thursday 5 March 2009 @ 10:47
Yes, the file open dialog can also trigger the exploit. But of course, Adobe Acrobat must be installed.
Comment by Didier Stevens — Thursday 5 March 2009 @ 11:30
You name this a “/JBIG2Decode vulnerability in PDF documents” – but isn’t the vulnerability in Acrobat, rather than the documents themselves? What happens with other PDF reader software? (These details are important.)
Comment by David Gerard — Thursday 5 March 2009 @ 14:16
I was told by @Marsmensch that Preview on OSX and Ghostview on Linux/OSX crash.
Comment by Didier Stevens — Thursday 5 March 2009 @ 14:24
Since this is an as-of-yet unpatched vulnerability, how does one disable the Explorer shell extension? (Standard disclaimer about mucking about in RegEdit applies, of course, but I’m not ‘fraid. Hit me with it, if you have it.)
Comment by Steve — Thursday 5 March 2009 @ 14:33
What’s not clear to me is that if one has javascript disabled in adobe reader preferences, will these vulnerabilities still occur? I.e., do the shell extensions use the same codebase as Adobe?
I’m also wondering if there’s a similar issue on other platforms that try to do previews of PDFs (Gnome, KDE).
Comment by Pat Murphy — Thursday 5 March 2009 @ 14:39
That’s the first report I’ve heard of such, thank you!
I’d have expected something like this given that *everyone* uses the official Joint Photographic Experts Group libraries. Is the problem traceable to those?
Comment by David Gerard — Thursday 5 March 2009 @ 14:41
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.
Comment by Didier Stevens — Thursday 5 March 2009 @ 15:02
Yes, the PDF Shell Extension uses the same codebase, it does this by loading the appropriate Acrobat DLLs.
As to JavaScript, it’s possible to exploit the /JBIG2Decode vulnerability without using JavaScript, and there are samples of this found in the wild.
Comment by Didier Stevens — Thursday 5 March 2009 @ 15:04
Yes, reading Florian’s remark, I’m convinced it’s a library issue.
Comment by Didier Stevens — Thursday 5 March 2009 @ 15:05
Handy. In followup, do we have any idea whether Adobe Reader notices when you disable its shell extension and “fixes” it for you? Hopefully not…
I’m pretty much assuming it’ll do that if you update Adobe Reader, though.
Comment by Steve — Thursday 5 March 2009 @ 15:13
No, and I would be surprised if it did this without you doing an explicit repair or reinstall.
Comment by Didier Stevens — Thursday 5 March 2009 @ 15:20
Well, seeing how difficult it can be to eradicate some start-up accelerators and keep programs from re-taking their file associations every time they’re run, it wouldn’t surprise me greatly.
Comment by Steve — Thursday 5 March 2009 @ 15:24
[…] de gevoeligheden in Adobe’s Acrobat Reader. Nu heeft de Belgische beveiligingsonderzoeker Didier Stevens een manier gevonden om, door gebruik te maken van de Windows Explorer Shell Extensie, de […]
Pingback by Ongeopende PDF bestanden kunnen uw computer toch besmetten « “Lost in the Noise” - Security Research Weblog — Thursday 5 March 2009 @ 16:07
Sysinternals (now owned by Microsoft) utility Autoruns also has the ability to display and disable these handlers. For this PDF handler, look in the tab “Explorer” under the section “HKLM\Software\Classes\Folder\Shellex\ColumnHandlers”.
http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx
http://technet.microsoft.com/en-us/sysinternals/default.aspx
Comment by Pas B — Thursday 5 March 2009 @ 17:13
[…] Adobe’s patch for the current PDF vulnerability still some time away, news has emerged of more techniques that are available to exploit the vulnerability, this time without needing the victim to actually […]
Pingback by PDF Vulnerability Now Exploitable | www.lievebeheersbeestjes.org — Thursday 5 March 2009 @ 18:16
February 20, 2009:
“Oh, by the way, I forgot to mention. If you happen to open an explorer window, or a browser window, or anything at all that even has the ICON of the pdf file, you’re owned.”
Comment by jbig — Thursday 5 March 2009 @ 19:19
You say it was done on a fully patched XP SP2 machine, why did you not apply SP3 on this machine? I don’t know specifics of SP3 so maybe it wouldn’t make a difference. Thanks for the article.
Comment by Deryck — Thursday 5 March 2009 @ 19:38
@jbig
“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.”
You didn’t follow the link I guess? You would have noticed that I link to the vrt blog.
Comment by Didier Stevens — Thursday 5 March 2009 @ 19:42
@Deryck
Because SP3 installs a couple of services I don’t want, like the client for NAP.
I don’t believe it would make a difference.
Comment by Didier Stevens — Thursday 5 March 2009 @ 19:46
#18 gave a possible solution to the vulnerability (at least temporarily), have you tested this yet?
Comment by Deryck — Thursday 5 March 2009 @ 19:48
I know Autoruns, and I know it disables Shell Extensions. But I haven’t tested it in this case, I just wanted to mention another tool than Mark’s ubiquitous Sysinternals tools 😉
Comment by Didier Stevens — Thursday 5 March 2009 @ 19:54
[…] click necessary to get owned. Quickpost: /JBIG2Decode Trigger Trio << Didier Stevens Tags: ( exploit pdf adobe infosce vulnerablility […]
Pingback by Interesting Information Security Bits for 03/05/2009 | Infosec Ramblings — Thursday 5 March 2009 @ 20:59
@18: I don’t have Adobe Reader on our systems, but I do have Adobe Acrobat on one of them. Long ago I disabled an entry for Adobe.Acrobat.ContextMenu from here:
HKLM\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved
Might that DLL (adobe\acrobat 6.0\acrobat elements\contextmenu.dll) or ones like it be exploitable as well?
I’ve always hated the fact that third party applications can easily and quietly hook themselves into Explorer, but recall the infamous WMF exploit of 2005 for an example of how even stock Windows DLLs can make the mere browsing of directories dangerous.
Comment by TJ — Thursday 5 March 2009 @ 22:51
[…] mitgr81 on Mar.05, 2009, under Daily List Security: PDF Exploit doesn’t require you to open the file. Thats’ crazy and fun! :Security No comments for this entry […]
Pingback by Daily List - MiT Gr8 1 — Thursday 5 March 2009 @ 23:30
How about the windows indexing service? This also reads PDF metadata as well as the content of the PDF. Vulnerable?
Comment by zal — Friday 6 March 2009 @ 0:36
[…] Slashdot, I just ran across Didier Stevens post on how to automate the JBIG2decode vulnerability in PDF documents. There is a video on the site where he runs through three […]
Pingback by More on PDF /JBIGS2Decode Issue | securosis.com — Friday 6 March 2009 @ 0:53
The vulnerability is in the Adobe Acrobat software. It not in Windows Explorer, and not in the PDF Shell Extension. The PDF shell extension is using a buggy DLL.
If you know that the windows indexing service is reading PDF content and metadata, then it must use Adobe Acrobat software (probably a DLL, maybe the PDF shell extension) and hence ultimately execute the buggy Adobe Acrobat JBIG2Decode code.
On a Windows XP SP2 default install, the index service is in manual start mode, so it’s not running by default. The bad thing is that it is running under the local system account.
Comment by Didier Stevens — Friday 6 March 2009 @ 9:26
[…] sarà pronta intorno all’11 marzo, secondo Adobe. Nel blog di Didier Stevens c’è un video con annotazioni tecniche che spiegano il meccanismo di azione di un esempio di PDF ostile che sfrutta questa […]
Pingback by Aggiornamenti e falle per Firefox, Microsoft e Acrobat « Paoblog’s Weblog — Friday 6 March 2009 @ 10:32
[…] JBIG2Decode Trigger Trio – [blog.didierstevens.com] […]
Pingback by Clickless PDF Vulnerability — Friday 6 March 2009 @ 13:35
You say that you trialled this on an XP SP2 machine. I take it that is with IE7 installed? Does this affect IE6 – I understand the way the URI is handled changed in IE7 which is what led to this exploit.
Comment by Shaun Thomson — Friday 6 March 2009 @ 14:52
Any chance an AV scanner would trigger the shell extension and buggy Acrobat code while scanning the file?
Comment by DavidL — Friday 6 March 2009 @ 14:57
No, you are referring to something completely different: http://www.gnucitizen.org/blog/0day-pdf-pwns-windows/
This has nothing to do with URIs and IE7, this is an bug in the parser for /JBIG2Decode compressed stream objects (a feature of the PDF language).
Comment by Didier Stevens — Friday 6 March 2009 @ 14:58
No, not that I can think of.
A modern AV comes with a File Filter System Driver, this is used for the on access scan, and it operates in the kernel. I doesn’t go through Windows Explorer + a shell extension.
Comment by Didier Stevens — Friday 6 March 2009 @ 15:03
Does it work focusing the file in any way? I mean, you could focus on the file with tabulator key or arrow keys, I think it’d “execute” anyway
Comment by Manu — Friday 6 March 2009 @ 19:05
[…] Full Story@ Didier Stevens […]
Pingback by PDF Vulnerability Now Exploitable With No Clicking | dralnuX.com — Friday 6 March 2009 @ 20:16
[…] file. As a proof, Didier Stevens, an IT security consultant at Contraste Europe, has just recently demonstrated, and was far more dangerous than Secunia’s exploit. As Didier Stevens described, there are […]
Pingback by Adobe Acrobat 0day Exploit | — Friday 6 March 2009 @ 21:25
[…] Quickpost: /JBIG2Decode Trigger Trio Sometimes a piece of malware can execute without even opening the file. As this is the case with the /JBIG2Decode […] […]
Pingback by Top Posts « WordPress.com — Saturday 7 March 2009 @ 0:21
Many thanks for bringing this to my attention. I’ve always felt uneasy about the image and info preview one gets by merely hovering over a pdf on xp, but it’s remained on my, “Must look into that later”, list – until now.
I disabled the video preview long ago for various reasons and see no hardship in kicking pdf into touch similarly.
Comment by domestic empire — Saturday 7 March 2009 @ 0:52
[…] the security flaw in more detail and has published a blog post that shows three ways the security flaw can be triggered without even opening the PDF […]
Pingback by Update on the Acrobat and Reader Security Flaw | 4xPDF Blog — Saturday 7 March 2009 @ 3:40
@Manu
I’ll have to test that.
Comment by Didier Stevens — Saturday 7 March 2009 @ 9:46
[…] If you’ve been living in fear of opening any suspicious PDF files since we let you know about a still-unpatched bug in Adobe Acrobat that could expose your PC to a malware infection, we’ve got some bad news for you: it turns out that, due to how the bug is integrated into the software, it’s possible for malware authors to still get into your system, even if you never actually open an infected file. […]
Pingback by Adobe Acrobat bug can lead to malware installs without even opening an infected file « I Am Rajendra - Watch The World With Me….. — Saturday 7 March 2009 @ 11:35
Metadata-exploits (Windows)…
Det finns vitt spridda föreställningar om att man kan undvika virus/malware genom att låta bli att ladda hem och öppna filer – vilket naturligtvis inte stämmer – drive-by downloading är ett känt problem som har funnits länge. Helt enkelt att an…
Trackback by Martin Holst Swende — Saturday 7 March 2009 @ 13:18
[…] integrato nel software>>, gli autori di malware possono portare infezioni nel nostro sistema senza “obbligarci” all’apertura di un file PDF opportunamente […]
Pingback by Il BUG unpatched di Adobe Acrobat non è di basso livello, è pericolosissimo » Italia SW — Saturday 7 March 2009 @ 14:15
[…] releases its patch next week, think again. Didier Stevens, an IT security consultant last week demonstrated that simply viewing the folder containing compromised PDF documents within Microsoft’s Windows […]
Pingback by A New Twist to the Adobe Vulnerability — Monday 9 March 2009 @ 0:15
[…] Filed under: Malware, PDF, Quickpost, Vulnerabilities — Didier Stevens @ 7:11 My previous blogpost showed how minimal user interaction can still get a malicious PDF document to infect a machine. […]
Pingback by Quickpost: /JBIG2Decode “Look Mommy, No Hands!” « Didier Stevens — Monday 9 March 2009 @ 7:12
[…] releases its patch next week, think again. Didier Stevens, an IT security consultant last week demonstrated that simply viewing the folder containing compromised PDF documents within Microsoft’s […]
Pingback by A New Twist to the Adobe Vulnerability | google android os blog — Monday 9 March 2009 @ 11:01
[…] Stevens, an IT security consultant has demonstrated how just VIEWING a folder containing compromised PDF files using Microsoft’s Windows […]
Pingback by Warning: New Adobe Vulnerability | Blippitt — Monday 9 March 2009 @ 20:00
[…] The exploit was also unwittingly given a helping hand by Windows Explorer Shell Extensions, allowing the malicious code to be triggered even without the user opening the bad PDF, (a proof of concept was posted by Didier Stevens here). […]
Pingback by TREND MICRO Countermeasures » Foxit PDF Reader beats Adobe to the patch. — Monday 9 March 2009 @ 22:14
[…] release one on March 11th) is a rather scary one. This type of vulnerability can be exploited without the user even opening the malicious PDF! How can you defend yourself against that?! You should have as many layers as possible in order to […]
Pingback by Perimeter defense is useless! | IT a digital life — Monday 9 March 2009 @ 23:50
[…] Illustra infatti Didier Stevens nel suo blog, che quando si installa Adobe Acrobat Reader, viene anche installata una apposita estensione della Shell, un particolare pezzo di codice chiamato COM object che fornisce a Windows Explorer dati addizionali per visualizzare nelle colonne “extra” quel determinato tipo di file, altrimenti considerato “sconosciuto”. […]
Pingback by Adobe Reader, lo stucco per le falle di Acrobat è in arrivo - The New Blog Times — Tuesday 10 March 2009 @ 23:01
rath의 생각…
Acrobat Reader도 해킹툴로 쓰일 수 있다니.. 게다가 PDF 파일을 열지 않아도 된단다. -_- 여튼 오늘 패치가 떴으니 Windows 에서 PDF 보는 사람은 꼭 설치하시길….
Trackback by rath's me2DAY — Wednesday 11 March 2009 @ 7:00
[…] releases its patch next week, think again. Didier Stevens, an IT security consultant last week demonstrated that simply viewing the folder containing compromised PDF documents within Microsoft’s […]
Pingback by A New Twist to the Adobe Vulnerability - Yudhitech DotNet — Wednesday 11 March 2009 @ 8:11
[…] bug che “consentiva agli autori di malware di portare a termine infezioni nel nostro sistema senza “obbligarci” all’apertura di un file PDF opportunamente modificato” (leggi l’articolo Il BUG […]
Pingback by Adobe rilascia finalmente la patch per Adobe Reader e Acrobat 9.1 » Italia SW — Wednesday 11 March 2009 @ 13:00
[…] about the vulnerability and proof-of-concept videos can be found here for the inquiring minds.PDF Exploit Search this […]
Pingback by OIT Software Support Blog · PDF Threat! — Thursday 12 March 2009 @ 16:59
[…] a few months, PDF files have been hit by several security issues and recently, a zero-day exploit targeted Powerpoint files. Why not use GMail as a sandbox? [If you […]
Pingback by /dev/random » Blog Archive » Use Google Mail as a Sandbox — Friday 24 April 2009 @ 20:02
[…] Dazu nutzt er die /JBIG2 Schwachstelle. Schon im März hatte der Security-Resercher drei Methoden vorgestellt, bei denen zwar keine Datei geöffnet werden, aber das Opfer immerhin noch passiv mitwirken musste. […]
Pingback by ψ² = Ps(i)² » Blog Archive » Wer hat an der Uhr gedreht… — Wednesday 10 June 2009 @ 9:20
[…] gezeigt, dass er irrt. Zu vier Angriffsvarianten die der Security-Analyst Didier Stevens vorgestellt hat berichtete ich […]
Pingback by Blog » Blog Archive » Und immer wieder PDF-Angriffe — Thursday 18 June 2009 @ 6:40
[…] inget om den är skadlig – den kan inte göra något. Didier Stevens har postat en video ( https://blog.didierstevens.com/2009/03/04/quickpost-jbig2decode-trigger-trio/ )på tre scenarior där malware lyckas exekvera utan att filen “öppnas” genom att […]
Pingback by Martin Holst Swende » Blog Archive » Metadata-exploits (Windows) — Saturday 21 November 2009 @ 21:26
#14: Yeah you’re right look what’s in pdfshell.dll
HKCR
{
NoRemove CLSID
{
ForceRemove {F9DB5320-233E-11D1-9F84-707F02C10627} = s ‘PDF Shell Extension’
{
InprocServer32 = s ‘%MODULE%’
{
val ThreadingModel = s ‘Apartment’
}
}
}
NoRemove Folder
{
NoRemove Shellex
{
NoRemove ColumnHandlers
{
ForceRemove {F9DB5320-233E-11D1-9F84-707F02C10627} = s ‘PDF Column Info’
}
}
}
NoRemove AcroExch.Document.7
{
NoRemove Shellex
{
ForceRemove {BB2E617C-0920-11d1-9A0B-00C04FC2D6C1} = s ‘{F9DB5320-233E-11D1-9F84-707F02C10627}’
NoRemove PropertySheetHandlers
{
ForceRemove InfoPage = s ‘{F9DB5320-233E-11D1-9F84-707F02C10627}’
}
}
}
}
Comment by Leeroy — Wednesday 25 November 2009 @ 0:14
[…] illustrato da Stevens all”interno del suo post, Adobe Reader si integra in Windows Explorer permettendo […]
Pingback by PDF a rischio exploit anche senza doppio click - CaptersTux — Thursday 18 February 2010 @ 17:19
[…] to name here because of SEO reasons), installs a Windows explorer shell extension (we’ve discussed the risks of these shells before). The problem with this tool’s shell extension (a DLL), is that it is compiled without the […]
Pingback by Quickpost: "It Does No Harm…" or Does It? « Didier Stevens — Monday 17 January 2011 @ 0:00
[…] Quickpost: /JBIG2Decode Trigger Trio « Didier StevensDS, Quick question, how many AVs on virus total detected these 3 pdfs properly … […] Slashdot, I just ran across Didier Stevens post on how to automate the JBIG2decode vulnerability in PDF documents. There is a video on the site where he runs through three […] […]
Pingback by Quick post | Wishka — Sunday 29 May 2011 @ 4:16