Universal PDF XSS After Party

Thu, 04 Jan 2007 12:14:52 GMT

Everybody knows about it. Everybody talks about it. We had a nice party. It is time for estimating the damages. In this article I will try to show the impact of the Universal PDF XSS vulnerability by explaining how it can be used in real life situations.

For those who has slept over the last two days, here is a short introduction of what this talk is going to be about:

The Universal PDF XSS issue was discovered by Stefano Di Paola and Giorgio Fedon and it was presented on 23C3 security conference. This vulnerability obviously affects the Adobe Acrobat Reader which is a widely used software among business, non-business organizations and individuals. By abusing Acrobat's open parameter features well protected sites become vulnerable to Cross-site scripting attacks if they host PDF documents. This is pretty bad and unless you update your reader or change the way your browser handles PDF documents, you may get hacked quite badly. This issue is very serious.

The way attackers use PDF documents to execute JavaScript code is outlined with the following template. The code will be executed on the domain where the PDF files is hosted on:


Now we know what we are going to talk about, lets have a look on how attackers can use this vulnerability to abuse your WEB presence.

First of all it will be good to mention that PDF is widely used document format. In fact, every major site (I don't want to say every site, although I wont be far from the truth) hosts at least one PDF document. This makes the situation a lot worse because If you happen to be on a malicious site or you click a malicious link, attackers can simultaneously compromise several of your WEB accounts that are currently open/authenticated.

For further clarification lets say that you have accounts in MySpace and Freindster and several other social networks open and then you visit a random page that has a XSS PDF exploit. The attacker that controls this page will be able to get your session ID on all of your social network profile pages and as such successfully hijack your identity. This is just one possible scenario. Attackers are also able to tamper your profile page in order to assure future access to your and your friends' profiles as well. That will happen in a matter of seconds so you can see that from this point on you have to be extra conscious with your WEB activities. Disable JavaScript or update to Acrobat 8.

I mentioned that either you have to click on a link or visit a page in order to get the exploit working. In general you need some type of user interaction. First of all, clicking on a link could be a bit suspicious if you think about it. Unless you really want to open a PDF document, there is no need for doing so. However attackers can make use of sneak techniques to force you somehow, by changing the file extension of the PDF document to .mp3 or .mov or even .html. It looks less suspicious, but still when pulled from the server the content will be served as application/pdf:

RewriteEngine On
RewriteRule *\.(jpg|png|css|mp3|mov|avi)$ http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf

If the user clicks on something like the following URL:


The code will be executed on Google not on currentdomain. The user has fallen into the trap. You can see that you should not trust links and your browser status bar because they could say something that is not really the truth.

It is also worth mentioning that there are many variations of this attack vector. In fact, there are so many variations that its not worth discussing all of them. However, here is another interesting one. I presume you are already familiar with TinyURL. In simple words, attackers can store an entire XSS vector for a specific site and recall it anytime they need it by using the TinyURL service. I shrunk the following URL which contains harmless XSS exploit for Google:


TinyURL generated the following shortened URL:


If you paste the above URL into your browser address bar you should get an alert message saying XSS. The ability for shrinking and obfuscating URLs with TinyURL and other technologies makes the Universal PDF XSS a pure evil. URLs are easily exchangeable via simple text messages, emails and IM chat sessions. The impact is huge.

The second way for getting the exploit working is by automatically opening it without user interaction, although the user needs to attend a malicious resource first. In order to make the vector working the attacker sets a hidden iframe that contains the malicious URL. Upon visit, the exploit executes.

<iframe src="http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:**code_here**" style="width:0;height:0;border:0"></iframe>

I mentioned that TinyURL can contain the entire XSS attack vector. Then you can easily execute it like this:

<iframe src="http://tinyurl.com/t8h4q" style="width:0;height:0;border:0"></iframe>

This is very bad because attackers can have multiple iframes in a single page that upon visit will exploit whatever WEB accounts you currently have open. It is totally stealth and extremely malicious.

Probably you are thinking that this can be used quite successfully to create a WEB worm infection. It is true! Obviously it is possible. A WEB worm of such a degree will be the first one that spreads on the top of the WEB without the restrictions introduced by the same origin security policy. The infection process can be very simple if you think about it. First of all the worm needs to have some kind of mechanism for discovering potential target. Google proves to be quite helpful with that. In this case either Google AJAX Search API (restricted) will be used or a hosted PDF document to do real Google searches on the main WEB Search interface (unrestricted). Once the worm finds a target, the infection algorithm is launched. Upon visit of a infected resource propagation process restarts.

It is also possible to have some sort of update mechanism for this type of worm. For example if one of the currently crawled sites contains XML comments with specially declared JavaScript code, the worm can mutate by adding the foreign code into its core. This way older generation worms can leave genetic code/clues for current generations. As you can see, this type of malicious code can be extremely dangerous and agile.

The Universal PDF XSS is probably one of the worst things that has happened to the web. This vulnerability affects almost every website. Here is another news for you: your local file system is subjected to external attacks as well.

The problem is that Adobe Acrobat comes with a couple of demo PDF documents. RSnake was first to report this specific attack vector. If you have Adobe Acrobat 7 you can execute JavaScript on your local filesystem. Because of the same origin policy, this JavaScript code can list your disk and send private files to a remote collection point.


You can see that the above URL is accessed with the file protocol. This means that we have access to other resources served by the same protocol. For more information how to access the file system, read the current user history file, dump the registry, download the SAM file or access other sensitive information read here and here.

This is why the situation is very bad not only for Adobe but also for the users and the security community. I did investigation to see what is the situation with most Social Networks that I know about. Almost all of them have PDF files. I wonder what will be next.

Does all this work if running from a Virtual Machine? How about if end user starts up browser from SandboxIE, what happens in this case? Just my 2/100$
you may want to check http://sla.ckers.org/forum/read.php?2,4785
PartyOf1, if you run in SandboxIE or Sandboxed FF then there will be no impact at all. If you are inside a Virtual Machine then only the emulated disk will be attacked. I guess you shouldn't be worried in that case.
file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#something=javascript:your_code_here How can an attacker exploit this? Because the user have to open this url directly for this to work. It can't be loaded into an iframe, or be redirected to by anything.
@luma: e.g. take the link, put it into a short url, (digg|delicuious|dzone) it or send it around via im and there you go...
luma, indeed... fortunately this is the case. However, we are hackers aren't we? So lets think outside of the box. I found a very simple technique for triggering the above URL automatically circumventing the browser same origin security policies. We can do that with QTL files. For more information how QTL files can be abused read here. Create a QTL file with mp3, mp4, mov, avi or qtl extension. Put the following content inside:
<?xml version="1.0">
<?quicktime type="application/x-quicktime-media-link"?>
<embed src="a.mp3" autoplay="true" qtnext="file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#something=javascript:your_code_here"/>
When the user visits the file, their local file system will be explored and dumped on a remote machine. It is a bit evil I know.
Richard MooreRichard Moore
Works comes with a PDF too and is almost always installed: C:\Program Files\Microsoft Works\wksgsg03.pdf
This doesn't work. It's all a hoax.
It works in FF2.0.0.1 but only when the Adobe plugin is used. If the action is "Open with default app" or "save to disk", the exploit does not work.
http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:alert('xss'); This did not work for me.I have acrobat reader 7.0 installed on my machine.it did not give an alert message on my browser.
h4ck, this is because google fixed it by adding the following header to the response:
Content-disposition: attachement filename=filename_of_the_document.pdf
I'm making a bit of an assumption here, but providing you type a direct URL into your address bar then, if the site itself hasn't been compromised, there is no chance of this vulnerability being exploited on a link created by the site owner. It only becomes a problem with user generated content, or in the case of a phishing attack. Am I right? Keith
The example did work for me. I am more interested in the "Content-disposition: attachement filename=filename_of_the_document.pdf".. is this a resolution for this issue?
KeithF, kind of... not completely. Yes, in certain situation the user has to click on a link. However, it is also possible for the attacker to launch an exploit automatically. Still a logged in user is required in order to gain the maximum benefit of the operation. The concept is exactly as the one found in XSS attack vectors. GE, yes this is what Google did to prevent their PDF files from being abused.
file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#a=javascript:alert('Hi'); Doesn't work for me in IE. Doc just opens. Also, are u limited to 32 characters for the parameter + value?
it works on very specific IE versions. Your Windows version and patch level also matters. There are no limitations.
in mac os x 10.4.8 ppc with safari 2.x or firefox 2.x doesn't work, mainly I Think because the acrobat 7.0.8 is called as an external application and not as a plugin
you could be right
It’s not occurs on IE 7, IE6 SP2 FF 2.0.2 , on windows XP ... If a user still didn’t understand that he needs to upgrade to the latest patch than maybe he deserve to be hacked…
From what I found (http://secunia.com/advisories/23483/) they claim that this can affect both IE and FF depends on the specific version of browser and acrobat. Although the alert did not work for me on FF (up to date this did work. file:///C:/Program%20Files/Adobe/Acrobat%206.0/Help/ENU/Pdfmark.pdf#a=javascript:window.location.href='http://www.google.com'; So my guess is the bug exists just because the plugin takes the window over, we don't get to see that window, however the bug does exist, and can be used. Joel
Everyone, I got http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here to run in FF on windows XP, but the file one did not run in that version
Jeremy HannonJeremy Hannon
Google may have changed their content-disposition to force the browser to treat it as a download rather than in-line. That appears to mitigate the threat.
Disable JavaScript or update to Acrobat 8.
Or disable Acrobat plugin, or even delete it. For your main browser or for all browsers in the system. There are many suggestions. Guys, as Google tell me, the are up to 317 000 000 sites in the Internet which have pdf files (and they all have this vulnerability). So every admin of every site and every user need to deal with this Universal PDF XSS.
This is already patched in Opera
i tried that link, and it doesn't alert me with xss, but it prompts me to download that pdf file. Im using firefox under ubuntu dapper
Nice Work.
Sebastian WolfgartenSebastian Wolfgarten
Hi, well one way to prevent people from exploiting your customers is to add the following directive to Apache's httpd.conf: Header unset Content-Disposition Header add Content-Disposition "attachment; filename=document.pdf" This will cause a save/open dialogue to pop up every time a user tries to download a .pdf file. As the "normal" Acrobat is not vulnerable (it's just the plugin), potentially attached malicious code will not be executed. If one wants to keep the original name of the .pdf file untouched, then one could use Apache's environment variables rather than setting it to "filename=document.pdf". Bye, Sebastian
Sebastian WolfgartenSebastian Wolfgarten
Okay, some stuff was stripped out from my previous posting...you basically need to wrap a FilesMatch-directive around the aforementioned "Header" settings... Hope that helps! Bye, Seb
thanks Sebastian, that was very helpful
seems to be fixed with the latest 7.0.9 patch...
hi nice site.
We allow users to try our software by uploading documents to an application we host. Some of the uploaded documents can be seen and accessed by other users. What kind of measures can we take so that users with older Acrobat versions are not compromised?
you just gotta convince them to get the newest version of Acrobat. That's why there are updates and improved versions, to fix the bugs and vulnerabilities of previous editions.
KeithF, kind of… not completely. Yes, in certain situation the user has to click on a link. However, it is also possible for the attacker to launch an exploit automatically. Still a logged in user is required in order to gain the maximum benefit of the operation. The concept is exactly as the one found in XSS attack vectors.