January 3, 2007
This article was contributed by Jake Edge.
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.
Comments (20 posted)
