Universal XSS in PDFs
This is what happens when I read too fast. I almost completely dismissed a recent writeup by Stefano Di Paola and Giorgio Fedon (thanks to pdp for doing a more thorough writeup). But it’s true, and PDF is vulnerable to XSS injection regardless if you have control over the PDF itself. Which means any website that has a PDF on it is now vulnerable to XSS injection.
The trick is simple: http://path/to/pdf/file.pdf#blah=javascript:alert(”XSS”);
Yup, like I said, simple. This is a really nasty issue, as any automatic redirection or getting anyone to click on a link can now compromise that website if they have Adobe’s PDF reader installed (which practically everyone does). This is one of the worst issues I’ve seen in a while, as almost every major website has PDFs on it (investor relations, white papers, sales sheets, etc…). You might want to remove your PDFs for the time being, protect them or at minimum host them on a domain you don’t care about.
January 3rd, 2007 at 11:05 am
omfg… my mouth is still open oO
great find @ the guys from 23c3, i’ll be there next year, too
January 3rd, 2007 at 11:14 am
pdp’s example is now down, but here’s another one in Google:
http://www.google.com/appliance/pdf/google_gsa_datasheet.pdf#blah=javascript:alert("XSS");
January 3rd, 2007 at 11:22 am
Various reports on compatibility
Works on:
Firefox 2.0.0.1 win32
Firefox 1.5.0.8 win32
Opera 8.5.4 build 770 win32
Opera 9.10.8679 win32
Does not work on IE7.0 win32
January 3rd, 2007 at 11:50 am
i cannot get this to work on any site with the ltest firefox and flock browser
January 3rd, 2007 at 11:52 am
If you are using RSnake’s example URL, make sure to change ”XSS” to “XSS”
January 3rd, 2007 at 12:18 pm
that google link didn’t work for me. sounds pretty crazy though
January 3rd, 2007 at 12:19 pm
Looks like attaching a “content-disposition: attachment” HTTP header to PDF files helps. That keeps the PDF file from opening in the reader plugin. I have the following directive in a ‘FilesMatch “\.(ppt|xls|doc|pdf)$”‘ container (apache):
Header append Content-disposition ‘Attachment’
January 3rd, 2007 at 12:21 pm
This is really sort of insane. Like you said, it’s simple, but nasty. Now its not really a question of ‘where’s the useful XSS vuln on target site?’ its more ‘oh hey they’ve got a PDF file… now just how do I want to use this againt them?’. This opens so many doors to exploitation, it’s not really even funny… Drive-by credential theft is the one that comes to mind first…
January 3rd, 2007 at 12:22 pm
Does not work with:
Intel
Safari 2.0.4 with Apple Preview (default MacOS X config)
Firefox 2.0.1 with Apple Preview (default if no AR installed)
I will try with Adobe Reader 7.0.8 and 8.0 later.
Andrew
January 3rd, 2007 at 12:25 pm
adam, which browser/acrobat version(s) are you using?
January 3rd, 2007 at 12:28 pm
wow.. just wow.
that’s ridiculous. i’m quite stunned .. and quite excited ^^;
and really, how often do people update their adobe reader - this one’ll be around for quite a while. and it makes me glad i use foxit reader instead of adobe
January 3rd, 2007 at 12:29 pm
Does not work with on MacOS X (Intel) with:
Safari 2.0.4 with Adobe Reader 7.0.8 (PPC binary)
Firefox 2.0.1 (does not integrate with AR 7.0.8 by default, not vulnerable
We’ve also had difficulty replicating this finding with IE 6.0 from XP SP2 and AR 7.0.8 on Win32.
It’s looking less and less likely to be a “universal” exploit.
Andrew
January 3rd, 2007 at 12:33 pm
Wow - that makes about 7 million vulnerable points of entry just for dot coms. Nice indeed!
Results 1 - 10 of about 7,040,000 from *.com for filetype:pdf. (0.13 seconds)
I tried a few, some work and others fail.
Any details as to _why_ this actually works?
January 3rd, 2007 at 12:57 pm
Thanks mgroves, I changed my link to use quotes instead of those weird fake quotes wordpress inserts.
January 3rd, 2007 at 1:43 pm
Doesn’t work for me on FF2 on mac.
But it is one scary attack vector..
January 3rd, 2007 at 2:21 pm
I think I may have found another issue in the adobe plug in, while I was playing around with this. It seems, atleast on my box, if you have an iframe pointing to a PDF file with an onLoad event, the adobe plugin will crash, displaying a message about how its preformed an illegal action, such as jaywalking. When you click OK, firefox hangs. This is on FF 1.5.0.9 on WinXP Home SP2
January 3rd, 2007 at 2:32 pm
[…] Wie auf ha.ckers.org web application security lab und GNUCITIZEN wird, sind PDF Dateien gegenüber XSS injection verletzbar, wenn man die Kontrolle über das PDF-File hat. Also ist jede Website die PDF Dateien enthält verwundbar. Es ist (leider) sehr einfach: http://pfad/zur/pdf/date.pdf#blah=javascript:alert(”XSS”); […]
January 3rd, 2007 at 2:32 pm
I deffinatly think I found something, but I want to play with it a bit more and find a surefire way to cause the crash, before I go out rambling about how to do it, so sort of ignore my previous post, ’cause the crash doesn’t seem quite as simple as that.
January 3rd, 2007 at 3:18 pm
Another post! Finished my little PoC drive-by credential theft script. Grabs your google.com cookie and displays it on the second page, source for both parts is available on the display page. http://newbert.org/pdf.htm is the link, if you’re interested.
January 3rd, 2007 at 3:54 pm
In the off chance that anyone is curious, here’s an example of a URL where the # effect is intentional:
http://www.google.com/appliance/pdf/google_gsa_datasheet.pdf#search=google
Not sure what else can be done with #’s…
January 3rd, 2007 at 4:16 pm
does not work in firefox 2.01 (linux)
January 3rd, 2007 at 4:43 pm
nah it does work i was just being a bit special
January 3rd, 2007 at 5:43 pm
Changing the mime type to something nonexistant should be the best solution for a site to perform (since users will never patch). Default behavior for unknown mimetypes is prompt to download.
- zeno
http://www.cgisecurity.com
January 4th, 2007 at 12:59 am
[…] Firefox->Tools->Options->Content->Manage->change PDF action to “Save todisk”. برای اطلاعات بیشتر در این مورد می توانید به نوشته Adobe Acrobat JavaScript Execution Bug is a Huge Security Issue مراجعه کنید. شروع اصلی بحث در لیست webappsec همچنان در حال ادامه است. مراجعه کنید به Universal XSS with PDF files: highly dangerous برای دیدن نظرات مختلف در این مورد. نوشته GNUCITIZEN در این مورد | نوشته ha.ckers در مورد PDF XSS […]
January 4th, 2007 at 2:22 am
[…] One blogger on the ha.ckers.org site wrote: “This is one of the worst issues I’ve seen in a while, as almost every major website has PDFs on it (investor relations, white papers, sales sheets, etc…). You might want to remove your PDFs for the time being, protect them or at minimum host them on a domain you don’t care about.” […]
January 4th, 2007 at 10:26 pm
Sorry for the delay, but the Adobe Security Advisory is up on this, with best info:
http://www.adobe.com/support/security/advisories/apsa07-01.html
tx, jd/adobe
January 24th, 2007 at 8:10 pm
All due respect…but there are plenty other issues with Acrobat reader besindes this security issue.
I’ll stick with something not so bloated and which doesn’t phone home.
http://listproc.ucdavis.edu/archives/linux/log0504/0004.html
http://lwn.net/Articles/129729/
January 24th, 2007 at 8:40 pm
Yes, but compared to compromising your machine, I think the phone home features are barely worth talking about, unless you are talking about how that correlates to CSRF - which is pretty bad.