DANGER, DANGER, DANGER

Wed, 03 Jan 2007 01:10:32 GMT
by pdp

The WEB has gone crazy. I know that this is not news for some of you but you will be surprised to what extend this craziness has just developed. Among the traditional QuickTime Movie, QTL, Flash, Image, HTML and PDF vulnerabilities, there is now another one trivially exploitable with somewhat high degree of impact.

So we have changed a lot of diapers last year. Simple things we do suddenly have become very dangerous and risky. If you think that user supplied Image files are safe, think again. There were several attacks affecting social networks and a couple of very successful AJAX worms, again affecting social networks, during the last year. However, it seams that we haven't really scratch the surface yet.

Back in September 2006 David and I had a small adventure with Adobe's PDF technology. David made several issues with JavaScript for PDF publicly available and the findings were quite shocking for many people including us. Today, it seams that PDF documents can execute JavaScript code for no apparent reason by using the following template.

http://**path/to/pdf/file.pdf**#**whatever_name_you_want**=javascript:**your_code_here**

You must understand that the attacker doesn't need to have write access to the specified PDF document. In order to get an XSS vector working you need to have a PDF file hosted on the target and that's all about it. The rest is just a matter of your abilities and desires.

This finding was originally mentioned by Sven Vetsch, on his blog. The attack vector was discovered by Stefano Di Paola and Giorgio Fedon. This is a very good and quite interesting finding. Good work.

Just to show you the impact of this issue I prepared the following POC.

[http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function createXMLHttpRequest(){   try{ return new ActiveXObject('Msxml2.XMLHTTP'); }catch(e){}   try{ return new ActiveXObject('Microsoft.XMLHTTP'); }catch(e){}   try{ return new XMLHttpRequest(); }catch(e){}   return null;}var xhr = createXMLHttpRequest();xhr.onreadystatechange = function(){    if (xhr.readyState == 4)        alert(xhr.responseText);};xhr.open('GET', 'http://www.google.com', true);xhr.send(null);
](http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function createXMLHttpRequest(){   try{ return new ActiveXObject()

When you open the PDF document, an XMLHttpRequest will be made to google.com and the front page source code will be displayed inside an alert box. Obviously, attackers can create a lot more dangerous scenario, where highly sensitive information is leaked leaving the user totally blind of what is going on.

This attack vector has several benefits that I must elaborate on. First of all, it is obvious that this is not a server side problem. This is totally client side and Web app owners cannot do much about it. The only solution is to have Adobe release a patch as soon as possible or just not to host PDF files at all. Obviously the second solution is highly unfeasible. This leave us with Adobe fixing the bug, but let's be honest with each other. Things won't get better. It is not that Adobe don't have good guys there or they are irresponsible. It is just the fact that not that many people update their PDF reader mainly because it usually requires a large chunk of data being downloaded and installed. The process is very slow and bulky and puts off even security-minded people.

Now we have a prove that every site on this planet is vulnerable to XSS (Cross-site scripting). This is definitely not nice. Unwillingly we have become solicitors of a very dangerous craft.

Archived Comments

pdppdp
BTW, on Window PRO SP 2, only FF is vulnerable.
Disenchant / Sven VetschDisenchant / Sven Vetsch
As I just added to my blog entry and wrote to the mailinglists: It seems that I didn’t copy paste the credits out of my document I wrote with the content of this entry :( Of course I’ve to give some credit to Stefano Di Paola and Giorgio Fedon because they found this flaw and not me at all. As you see, I edited my blog entry. Next time I’ll be more careful and perhaps don’t write blog entries when I’m as tired as I was when I wrote it. @pdp Please also edit your blog entry. thx
David KierznowskiDavid Kierznowski
pdp, I haven't tested this yet but it looks like a great find. Users with Foxit PDF viewer are not vulnerable to this; at least those without the JavaScript plugin installed (the default). So those who learn't last time round should be ok.
pdppdp
Sven, fixed!
Tester ZeroTester Zero
This flaw could be really bad. Think of all those pfd files hosted by online banks. http://www.google.com/search?q=site%3Abankofamerica.com%2F+inurl%3Apdf&btnG=Search A phisher could do some real damage.
Jason DukeJason Duke
It seems to not be replicatable on IE6 or IE7 for me, although is with FF. Any thoughts ?
pdppdp
Tester Zero, indeed. Jason, yes... although some people are getting different results. For example, the following conditions are exploitable:
  • IE 6 SP 1 with version of Acro Reader older than 8.0
  • Firefox 2.0.0.1 win32
  • Firefox 1.5.0.8 win32
  • Opera 8.5.4 build 770 win32
  • Opera 9.10.8679 win32
The damage is huge.
sasosaso
according to the this page from the original author of this article from CCC this is already fixed in adobe acrobat 8 (as far as we talk strictly about the pdf issue since the original topic of the article is more wide/general about ajax/web2 attacks) http://www.wisec.it/vulns.php?page=9
mikemike
It doesn't work in Linux I tried - kpdf - evince - adobe reader 7.0
pdppdp
mike, it affects strickly Adobe Acrobat. saso, several researchers report Acrobat 8 as one of the vulnerable. I guess it depends on that platform and the current acrobat patch level.
KrisKris
I couldn't replicate it on IE7 with either reader 7 or 8 at all, although I could reproduce the problem on FF. Now I'm starting wonder how huge this really is: Acrobat 8 has been out for at least 6 months, IE7 for 3 or so, and is getting a major push from MS. Either update will fix the problem, and what, 85% or so of the world is still on IE? It's definitely still a big deal, but it's not something companies with a decent software update policy will need to lose sleep over right now.
daviddavid
I've seen a couple of places that the "wprkaround" is to turn off JS in your browser. From the client-side, wouldn't it be sufficient to just remove/replace the Adobe Acrobat browser plug-in?
SmaxorSmaxor
Doesn't seem to work in IE6 with Acrobat 7.
CumpsDCumpsD
Windows 2003 R2 SP1, x64, FF 1.5.0.8, Adobe Reader 7.0.8: PoC worked. Fixed it by telling FF to give me the download box for pdf files in the future :)
pdppdp
Kris, I see you point of veiw but I don't quite agree with it. IMHO, this vulnerability will be present for a while. In fact, I can see some development on new types of WEB worms that can simulationsly spread over several social networks. The impact of this issue is huge. Web worms can use Jeremiah's css history dump and login detection hacks together with the Google AJAX Search API hack in order to create a massive WEB infection. In fact, such type of malicious code can be trivially composed in half an hour. This is a vary scary thought.
pdppdp
Smaxor, what's your patch level? I have a sneak suspecion that the IE POC works on different SPs.
Leonard RosentholLeonard Rosenthol
A couple of points on this... 1) This issues ONLY effects the Windows platform. Mac, Linux, etc. users are NOT effected. 2) We found this issue out ourselves during our own security/vulnerability testing of Acrobat and introduced a fix as part of Acrobat/Reader 8 for Windows. As such, users of Acrobat/Reader 8 (regardless of browser) are NOT EFFECTED! 3) We already have patches prepared for earlier versions of Acrobat and will release those as soon as they are ready. This will address those users who are unable/unwilling to upgrade to Acrobat/Reader 8. We thank the community for their concern in identifying vulnerabilities in our products and hope that our having the issues already addressed in our current versions will serve to alleviate concerns and demonstrate our commitment to this area. Leonard Rosenthol Adobe Systems
pdppdp
Leonard, I am not surprised that actions has already been taken. I remember the last time your company respond was quite on time. The one million dollar question is: how quickly your update will propagate? I think this is the concerning bit emerging from the current situation.
kirsplatkirsplat
It does work on Linux - FF: 1.5.0.9 + adobe reader 7
RossRoss
The concern I have is that we have a very tight security policy here and this is the first bug I've seen in about 18 months that's actually going to affect us. Here we have to use IE but only trusted sites are allowed to run any kind of Javascript, ActiveX control, etc. Non trusted sites can't even open PDF files directly so ordinarily vulnerabilities don't affect us at all. However this bug appears to allow an untrusted site to open a PDF from a trusted site and I can only assume that means it will run the code from the security context of the trusted site too. That is a very serious concern for us. My other concern is that Acrobat Reader is a nightmare to update, it's one of the worst programs we have for deploying updates, and I can see this being a popular attack vector because of it's widespread use and the problems updating it. We'll get Acrobat updated on our computers today, but I wonder how long this vulnerability would have gone quietly unnanounced by Adobe...
.mario.mario
And now it's local - credits for the basic PoC go to RSnake. click here
BernhardBernhard
I could reproduce with FF 2.0.0.1, Acro 7.0.8 on Win32 EVEN through Acro had Javascript disabled. Obviously, this only affects JS _inside_ the PDF.
Rodrigo PeresRodrigo Peres
Tested here with Win 2K SP4, IE6 and Adobe 7.0.5. Seems not vulnerable.
IT BlogwatchIT Blogwatch
Pesky PDF problems panic punters (and OpenTom)... Don't click that PDF! IT Blogwatch explains: researchers found a nasty bug in Adobe Acrobat. Not to mention how to install your own software onto a TomTom GO satnav......
MichielMichiel
I was going to say "it doesn't work for me" but then I remembered I uninstalled Adobe PDFbloater and installed Foxit. Yay foxit!
pdppdp
btw, here is an updated list of exploitable versions. the info is provided by acidus Effected Browser: (all on Windows)
  • IE6 + Acrobat Reader 7 + XP SP1
  • IE6 + Acrobat Reader 4 + XP SP2
  • (possibly) IE 6 on non-XP platforms
  • Firefox 2.0.0.1
  • Firefox 1.5.0.8
  • Opera 8.5.4 build 770
  • Opera 9.10.8679
pdppdp
update from acidus
  • IE6 + Acrobat Reader 4 + XP SP2
  • IE6 + Acrobat Reader 6 + XP SP2
  • IE6 + Acrobat Reader 7 + XP SP1
  • (possibly) IE 6 on non-XP platforms
  • Firefox 2.0.0.1
  • Firefox 1.5.0.8
  • Opera 8.5.4 build 770
  • Opera 9.10.8679
darrondarron
What about forcing the PDF to download instead of displaying it in the browser with the plugin? Kind of like this.
John DowdellJohn Dowdell
Hi, I'm sorry for the wait on this, but the Adobe Security Group has the full advisory published now: http://www.adobe.com/support/security/advisories/apsa07-01.html If you've updated your internet software since last autumn then you're already covered, with the free Adobe Reader 8. (This info was available in Stefano & Giorgio's initial paper, and in the CERT advisory.) As Leonard advised, patches for those who cannot update to the current version (old OS, locked intranet etc) are expected for download next week. tx, jd/adobe
James PulverJames Pulver
I can't get this to work in FF 2.0.0.1 with Acrobat Reader 7.0.5 or in Opera 9.10 ... Does this only work if you use the plugin? I have both set to open in Acrobat Reader, so I get a download box, and then Acrobat Reader opens up...
pdppdp
this is because Google fixed it by adding the following header to the response:
Content-disposition: attachement filename=filename_of_the_document.pdf
try
http://www.foia.cia.gov/2020/2020.pdf#something=javascript:alert('xss');
James PulverJames Pulver
Still no popup in Opera 9.10. Got it in FF2.0.0.1.
Ankit SinglaAnkit Singla
Running FFx 2 and Reader 8, I got an alert that said "This operation is not allowed" and then the adobe pdf file opened correctly using the second link. The first link doesn't tell the browser it's a pdf so it didn't open using the plugin.
Kent BrewsterKent Brewster
To help mitigate this problem at the server end, the following Apache URL rewrite rules:
RewriteCond %{HTTP_HOST} ^.*yourdomain\.com$ [NC]
RewriteRule ^(.*\.pdf)$ http://%{SERVER_ADDR}$1 [NC,R]
... should redirect requests for PDFs hosted here:
yourdomain.com/yourdir/your.pdf
... to here: youripaddress/yourdir/your.pdf Since you're probably setting cookies on your domain and not your IP address, most XSS approaches should hit a wall.
Dixie ScottDixie Scott
I have Windows 2000 Professional, IE6, Acrobat Reader 4.0. Does this affect me? I have my bank online and pay bills online with my checking acct. Am a student online also. Should I delete it? Cannot get higher version with win2k.
MustLiveMustLive
BTW, on Window PRO SP 2, only FF is vulnerable.
Not just FF, but also Mozilla which I use (Mozilla 1.7.7) also have this issue. On Win XP Pro SP2 (and most probably XP HE also as previous Windows XP, such as Gold and SP1). Just need Acrobat plugin installed in your browser.
MustLiveMustLive
It is realy danger and widespread vulnerability, boys. The are up to 317 000 000 sites over the Web which have pdf files (as Google said). And every admin of every site need to deal with this Universal PDF XSS.
RDPRDP
Using XP SP2, FF 1.5.0.9, PDF Downloader 0.7.6 and .8, and AR 7.0.8 and now AR7.0.9 - Uh... no change. The CIA link above still pops the XSS windows with 7.0.9 (even after rebooting) Moving on to 8
pdppdp
RDP, that's interesting. Anyone getting similar results?
gnugplgnugpl
I cannot reproduce the problem with xpdf and firefox on debian.
MustLiveMustLive
This is very widespread vulnerability. I have already written my own article about UXSS (in Ukrainian). And you may look at this example of such hole at microsoft's site :-). http://www.microsoft.com/windows2000/docs/TCO.pdf#xss=javascript:alert('XSS')
SneakyWho_am_iSneakyWho_am_i
At the time it would have meant that probably thousands of customers at my particular bank using IE6 and Firefox 2 were affected. While the number of vulnerable clients should be significantly lower now, I would still avoid offering PDFs in the vulnerable configuration at least until IE6 goes byebye, if it ever does. I think that a place like a bank simply could not afford to let even one or two customers log in affected by a bug of this magnitude, per year. Granted, banks probably have unique IDs on all their forms and yada yada yada... But every exploit you allow is a piece of the puzzle for a nice combined exploit that crumbles your bones to dust in the advent of Murphy's Law. You can't win forever et cetera et cetera....