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 |
