A Firefox PDF plugin XSS vulnerability
A particularly nasty cross-site scripting (XSS) vulnerability has surfaced that impacts Firefox users who have installed the Adobe Reader (Acrobat/PDF) plugin. Proof of concept exploits have been published on Bugtraq as well as several blogs (here for example). Adobe has fixed the problem in Acrobat version 8; which is only available for Windows, no word yet on a fix for the Linux plugin (which is based on Acrobat version 7).
The technique was first disclosed last week at the 23rd Chaos Communication Congress by Stefano Di Paola and Giorgio Fedon in their Subverting AJAX presentation. Sven Vetsch discovered another wrinkle and publicized it on his blog. The crux of the vulnerability is a link with a URL of the following form:
http://host/path/to/file.pdf#anystring=javascript:malicious_code_here
The host and path to file are legitimate URL paths to a PDF file that is
hosted somewhere on the net, quite possibly at a site that is trusted
by the user. The attacker need not have any access to the PDF file,
but can have his code executed while appearing to be a simple download from
the affected site. It is the ability to turn any PDF hosted on any site
into an XSS attack that makes this vulnerability so insidious.
The vulnerability exploits a feature of the Adobe plugin that is not shared with other mechanisms for viewing PDFs from the web (including using the acroread external program that is also supplied by Adobe). Arguments can be passed to the plugin via the information after the '#' and can be used to specify a specific page or search string in the PDF. It can also be used to populate PDF forms using '#FDF=URL' arguments and the information for the forms is retrieved from the URL. Evidently Adobe does not check for FDF or two other similar argument types (which is why 'anystring=' works) and blindly asks the browser to fetch the URL specified. If the URL is javascript code as described above, the plugin does not detect that case and in effect forces the browser to execute it.
Any site hosting a PDF file is vulnerable and there is little that the site can do; there is no indication that the request is anything out of the ordinary because the string after the '#' is not passed as part of the request. Concerned sites could stop hosting PDF files, but that seems rather unlikely. Other server-side solutions are being discussed as there is a concern that users are unlikely to upgrade their browser plugins. Hosting sites would much rather that they be in control of whether their PDF files can appear in links with malicious content. Most XSS problems can be handled by proper server side filtering of user supplied content, but this particular vulnerability is different.
So far there are no reports of other PDF plugins that follow Adobe's lead in retrieving URLs that appear in links to PDF files. In this author's experience, PDF viewing utilities are separate programs that get invoked by the browser after it downloads a PDF file. For xpdf and kpdf (and presumably others), this works just fine but Adobe chose to provide a means of more closely integrating PDF viewing into the browser. Unfortunately, the fact that this plugin is closed source implies that users, especially Linux users, must wait for Adobe to fix the problem. We cannot fix it ourselves.
One could certainly imagine a similar mistake being made by one of the other PDF viewer development teams; Adobe is hardly alone in making bad choices in developing software. However, the fix for an open source PDF viewer would likely be available within hours of the report. Adobe was notified about this problem on 15 October according to the advisory, but there is still no fix for Linux. Disabling the plugin would seem to be prudent.
Fixing the affected software is just the start of the task of fixing the overall problem. As mentioned above, users are not particularly good at picking up security fixes even when they know about them. Getting the message out on this particular problem is a big hurdle. The alternative is to educate users so that they can recognize maliciously crafted links to PDFs and that is almost certainly a harder task.
The potential for a widespread outbreak exploiting this vulnerability is fairly high and this will probably not be the last we will hear about it. It certainly has the possibility of damaging the reputation of PDF amongst even casual web users and that is probably keeping some folks at Adobe awake at nights.
| Index entries for this article | |
|---|---|
| GuestArticles | Edge, Jake |
Posted Jan 4, 2007 17:22 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (11 responses)
Just out of curiosity, is there any motivation for GNU/Linux users to even use Adobe's PDF reader/plugin? I'm quite happy with my choice of KPDF, XPDF, and GPDF. I choose to view PDF files downloaded from the Internet in the separate viewer application, and I configure Firefox's MIME handler to open the appropriate application. Is there something I'm missing by avoiding Adobe's PDF viewer?
Posted Jan 4, 2007 18:51 UTC (Thu)
by kamil (guest, #3802)
[Link]
Also, it's been my experience that acroread is in general more reliable in displaying PDF documents properly: no weird formatting problems and such. But I haven't tried recent versions of k/x/gpdf, so they could very well be better in this regard these days.
Having said that, I never enable the Adobe PDF browser plugin. It always seemed counterintuitive to me to have PDF documents displayed in a web browser. Last I checked, it also caused problems when switching the PDF viewer to fullscreen and back.
Posted Jan 4, 2007 19:00 UTC (Thu)
by jwb (guest, #15467)
[Link] (5 responses)
That said, I never use the browser plugin.
Posted Jan 5, 2007 8:35 UTC (Fri)
by Los__D (guest, #15263)
[Link] (4 responses)
This includes quite a bit of datasheets from Atmel, Micrel, Microchip (damn I hate PICs), Epson, TI, National, and way too many from suppliers that still think that photographs put into PDF's are perfectly acceptable.
Posted Jan 5, 2007 18:15 UTC (Fri)
by jwb (guest, #15467)
[Link] (3 responses)
http://tastic.brillig.org/~jwb/evince-vs-adobe.png
Posted Jan 6, 2007 5:51 UTC (Sat)
by Los__D (guest, #15263)
[Link]
But about lineart; I did a few comparisons myself a couple of months back, on an e-ticket, there was a little logo, which at 100% looked a bit nicer in acroread, but when you zoomed in, it actually looked nicer in Evince than in acroread... Maybe they just have differing rendering settings at different zoom levels, or something.
Dennis
Posted Jan 8, 2007 23:35 UTC (Mon)
by roelofs (guest, #2599)
[Link]
Very nice, thanks. That matches my own gut impressions: Adobe uses some very nice scaling and interpolation algorithms in its PDF viewers, not only on fonts but also on vector lines (as here) and on embedded bitmaps like scanned US patents. And they're reasonably fast at it, too. I can't tell if it's full multitap resampling, but...nice (to quote Borat).
I have no doubts free software will catch up before very long, though I am a little surprised we're not there already. (Different priorities, I guess. :-) )
Greg
Posted Jan 11, 2007 17:29 UTC (Thu)
by endecotp (guest, #36428)
[Link]
The anti-aliasing issue should be fixable - plenty of OSS graphics libraries can already do this. Getting the font rendering right is also possible - for example FreeType2 can do hinting - but it is patent-encumbered.
Posted Jan 5, 2007 12:14 UTC (Fri)
by wookey (guest, #5501)
[Link]
I posit that most users would find the free PDF viewers entirely adequate these days, and certainly if Adobe's has this serious flaw then stopping using it is the obvious thing to do. Hopefully some people who haven't used the free viewers for years will try them again as a result of this and be pleasantly surprised at how well they work now.
Posted Jan 5, 2007 14:03 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (1 responses)
I have documents that I can only print in acroread; [xk]pdf just happen to do nothing, without any error message.
For some documents, acroread is much faster when one changes pages. One pays with the very long startup time, though.
Selecting texts (copy & paste) works better (that means: UI is more intuitive, action is more often successful) in acroread.
OTOH, I use xpdf a lot more than acroread due to its fast startup time. I use it also more often than kpdf since its desktop real estate need is smaller. I would never use any of these tools as browser plugin, though -- I want to have such documents in their own top-level windows.
Joachim
Posted Jan 10, 2007 3:02 UTC (Wed)
by droundy (subscriber, #4559)
[Link]
Posted Jan 5, 2007 16:01 UTC (Fri)
by k8to (guest, #15413)
[Link]
The plugin has become a clunkier, crashier acroread that takes out your browser with it.
Posted Jan 4, 2007 18:59 UTC (Thu)
by emgrasso (subscriber, #4029)
[Link] (1 responses)
Does this vulnerability also affect browsers like Konqueror that can load
Is there a clean way to uninstall the Adobe plugin if it is present? And a
Posted Jan 4, 2007 20:26 UTC (Thu)
by glettieri (subscriber, #15705)
[Link]
Posted Jan 4, 2007 23:02 UTC (Thu)
by spitzak (guest, #4593)
[Link]
Posted Jan 5, 2007 18:04 UTC (Fri)
by amarjan (guest, #25108)
[Link]
Posted Jan 8, 2007 23:43 UTC (Mon)
by roelofs (guest, #2599)
[Link] (2 responses)
Another one I saw (beyond the linked token_query suggestion) is to have the server mark PDFs as attachments, which forces them to be downloaded. It's not as convenient for users, but it completely bypasses the broken plugin.
Greg
Posted Jan 9, 2007 7:51 UTC (Tue)
by ldo (guest, #40946)
[Link] (1 responses)
Web browsers don't seem to pay any attention to a "Content-disposition: attachment" header line. The only reliable way we found to stop downloads from displaying in the browser was to add an ONCLICK attribute to the link, something like this:
Posted Jan 9, 2007 17:19 UTC (Tue)
by roelofs (guest, #2599)
[Link]
But the whole point (as I understand it) is that you don't control the link--the bad guy does (e.g., a phishing site or somebody else's cracked site). And his link certainly won't include that onclick/save-to-disk function.
(Of course, you were probably referring to historical attempts to prevent inline display, not something in response to this latest threat, which is a useful data point either way.)
Greg
Posted Jan 9, 2007 14:50 UTC (Tue)
by hein.zelle (guest, #33324)
[Link]
A Firefox PDF plugin XSS vulnerability
Some PDF documents allow you to fill in some information before printing them out. Many application forms in PDF act that way. Can you fill in PDF documents using k/x/gpdf? You can with acroread.A Firefox PDF plugin XSS vulnerability
The quality of the rendering in Adobe Reader is far higher than any of the free clones. I spend a good chunk of my time reading data sheets for electronic components and they are pretty well unreadable in Evince/XPDF/KPDF. In Adobe Reader they look tremendous.A Firefox PDF plugin XSS vulnerability
Strange, I use quite a bit of electronic datasheets, and all of them them has looked perfect in Evince so far. (And yes, I have done comparisons to be sure, as I also have had less than acceptable results in the past).A Firefox PDF plugin XSS vulnerability
Well, here's a comparison of Evince 0.6.1 versus Adobe Reader 7. I think you can see the difference in the quality of the line art.A Firefox PDF plugin XSS vulnerability
http://tastic.brillig.org/~jwb/evince-vs-adobe2.png
I'm afraid that I'll have to wait until the 9th to check them out, I'm in Beijing right now, visiting my wife's parents, and since an earthquake took out the Chinese main Internet line, I'm browsing pages at around 2kB/s (On &*^$%@$#*&* IE/Windows)... After 5 minutes, I could more or less only see the top bar, and a little of the windowbar on one of the pictures, still nothing on the other...A Firefox PDF plugin XSS vulnerability
Well, here's a comparison of Evince 0.6.1 versus Adobe Reader 7. I think you can see the difference in the quality of the line art.
A Firefox PDF plugin XSS vulnerability
In your examples, the line art is anti-aliased in Acroread but not in Evince, and I think that the fonts are hinted in Acroread but not in Evince. These examples are consistent with what I've seen: you need to zoom in one or two more steps with xpdf to see the same amount of detail that you'd see in the Adobe product.A Firefox PDF plugin XSS vulnerability
I have not used acroread since about 2002 and in the last year or so I have found that just about all PDFs finally render fine under either evince or xpdf (it used to be necessary to try 2 or 3 free viewers and still some docs gave problems). But there are still things that acrobat does better than the free browsers (I have found two bugs in fairly obscure area grouping opacity (or something like that) and clipping in the last two weeks due to some intensive use of therion, which aparently do not occur in acrobat). And there is the form-filling thing, which I have never missed, but some people might.A Firefox PDF plugin XSS vulnerability
Acroread has the ability to add comments, e.g., during review cycles. (One needs to have Acrobat for creation of such PDF documents, though.)A Firefox PDF plugin XSS vulnerability
Are you aware that you can configure kpdf to show nothing but the document? It's hard to beat that, in terms of screen real estate. This is what switched me from gv over to kpdf (that and kpdf is the first pdf viewer to obtain a decent "watch file" capability).A Firefox PDF plugin XSS vulnerability
No, there is basically no advantage to the browser plugin. It used to be that the browswer plugin was more networked than acroread, for things like hyperlinks outbound from the pdf back to the web. But acroread has sprouted sufficient tentacles to fill in such gaps.A Firefox PDF plugin XSS vulnerability
Two questions (Well, two and a half):A Firefox PDF plugin XSS vulnerability
Firefox plugins?
good way to find out whether it is present and active?
If you type "about:plugins" as url, you will get a list of installed plugins. To remove acroread, you should find the directory where firefox plugins are installed (/usr/lib/nsbrowser/plugins on my Gentoo box, but maybe /usr/lib/mozilla-firefox/plugins on other systems) and remove the file or symlink "nppdf.so".A Firefox PDF plugin XSS vulnerability
Can't this be fixed by changing whatever code the Adobe plugin calls to retrieve the url? It probably should just get the data and not execute anything. It would seem this may be a good idea in general as it would fix any broken plugin that intends simply to get some info from the net and did not intend to change the state of the browser.Can't this be fixed in Firefox?
As mentioned on the WEB SECURITY mailing list, services like tinyurl.com can be used to hide malicious URLs, so user education in this case would be even less effective than usual.A Firefox PDF plugin XSS vulnerability
Other server-side solutions are being discussed as there is a concern that users are unlikely to upgrade their browser plugins.
server-side solutions
server-side solutions
<SCRIPT>
function PleaseSaveToDisk()
{
alert("Please right-click and save the item to disk.")
return false
}
</SCRIPT>
<A HREF="link-to-whatever" ONCLICK="return PleaseSaveToDisk()">
Web browsers don't seem to pay any attention to a "Content-disposition: attachment" header line. The only reliable way we found to stop downloads from displaying in the browser was to add an ONCLICK attribute to the link, something like this:
server-side solutions
Would it be worth considering a workaround in the browser (firefox in this case) instead of the plugin? It's not firefox's fault, but at least the firefox source code is available so something could potentially be done about it. Firefox also has an update system which might work better than relying on users upgrading their acroread plugin.A Firefox PDF plugin XSS vulnerability
