patching Adobe’s hole

At this point most readers of this blog will have noticed the latest Adobe Acrobat security issue (see links at the bottom of this post if you haven't). In brief, an Acrobat PDF plugin feature lets an attacker run JavaScript of their choice on any site that hosts PDFs.

To put that into perspective, I am aware of several online banks that have a "mailbox" feature where you can see official letters from the bank to you in a PDF format. A malicious attacker could gain complete control of your online banking interface, for example inject malicious code to perform money transfer, by making you click a link of the form

Even if you are technical enough to check that protocol and hostname of that link are OK, it is easy to overlook the abnormal and dangerous bit at the end. And it works in any browser using the NSAPI plugin – for example Opera and Firefox. This exploit is very dangerous indeed!

The blame and responsibility for fixing it lies with Adobe. Fortunately, they've resolved the issue in Acrobat Reader 8 – but most users are as we know slow at updating their systems..

So, I'm happy to announce that most cases of this exploit no longer work in Opera.

Yesterday we published a browser.js update for all public versions of Opera greater than 8.01 which disables the exploit for all files that have a .pdf extension. Normally, this update will be downloaded by all Opera installations within a week from now – to get it faster just choose "Help > Check for updates". You may see a message saying no updates are available but the new browser.js will have been downloaded.

I will work a bit more on the patch to see if I can write a version that gives complete protection also for files without .pdf in the address, but you're already much safer with PDF security patch version 1.

It's the first time we've published a generic security issue fix in browser.js. Hopefully it won't happen often but it is interesting to see site patching applied in the security domain.

More information about the security issue and its consequences:

Official advisory:

Other related links:

And, in case you're curious this is the patch itself (in a somewhat more readable format than in browser.js itself):

opera.addEventListener('BeforeJavaScriptURL', function( e ){
	var pathname=unescape(self.location.pathname.toLowerCase());
	var hash=unescape(self.location.hash.toLowerCase());
	if( pathname.indexOf('.pdf')>-1 && hash  &&  hash.indexOf('javascript:')>-1   ) e.preventDefault();
}, false);

12 thoughts on “patching Adobe’s hole

  1. @hallvordI had heard about this, but now that you go into a bit of detail it confuses me, haha. If an attacker were to attempt this hack, would it affect the entire domain? Say if I upload pdfs to my own personal site, if someone tried this with the pdfs on my website, could they alter the files on the server with this..? or is it that they have to make a connection with someone first? Maybe I misunderstood it all, haha.Glad to see the browser.js being used for security purposes as well.

  2. kyleabaker: if your site has user accounts and login features, an attacker could make a user click on a link and steal that user's identity, see that user's information or do things on that user's behalf. Your files or the server would not be affected.

  3. 1. What's the point of supporting javascript in a pdf plugin ?2. How did this problem went unoticed for so long ?3. Why is Adobe Reader so damn bloated ? (foxit worray !)

  4. I get a "Could not complete check" warning dialog box when using "Check for updates" on the Help Menu. It says the following:The language currently set is not on the list of supported languages. Opera is therefore unable to determine which is the most recent version available for your language.My language is English-US.

  5. 1. What's the point of supporting javascript in a pdf plugin ?

    It doesn't look intentional to me. It looks like they invented a general syntax for somehow including "third-party" content by URL and overlooked the fact that the URL might start with javascript: and thus be executed as a script.

    2. How did this problem went unoticed for so long ?

    It is a general problem that not all plugin vendors understand the browser security model. They don't have to understand it. The old NSAPI specification has no security-related features really, and no concept of cross-domain/XSS limitations so any NSAPI plugin is free to request data from and send data to any site. Hence, plugin authors do not necessarily care about the web's security concepts or exploits. Plugin functionality that interacts with the browser in possibly security-sensitive ways may not be tested by the vendor (or anybody else) with security in mind.If you are concerned about security, it is useful to try to limit the plugins available on your system. Keep only the most necessary ones and perhaps make file types you know you sometimes want to see open in the related application instead of inside the browser. (Be sure to know what you are doing so that you don't do this for any executable types!)

    3. Why is Adobe Reader so damn bloated ? (foxit worray !)

    Sorry, I can't help you with that. Might this help?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s