patching Adobe's hole
Saturday, 6. January 2007, 23:58:45
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
https://examplebank.com/mailbox/letter1.pdf#arg=javascript:some_javascript_here
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:
http://www.adobe.com/support/security/advisories/apsa07-01.html
Other related links:
http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.securityfocus.com/brief/401?ref=rss
http://www.symantec.com/enterprise/security_response/weblog/2007/01/when_pdfs_attack.html
http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/
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);
By Saddle Magic, # 7. January 2007, 02:07:05
By jp10558, # 7. January 2007, 02:12:38
I 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.
By kyleabaker, # 7. January 2007, 04:17:57
By hallvors, # 7. January 2007, 14:47:49
2. How did this problem went unoticed for so long ?
3. Why is Adobe Reader so damn bloated ? (foxit worray !)
By xErath, # 7. January 2007, 23:21:40
By Darken, # 7. January 2007, 23:59:10
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.
By TreeGo, # 8. January 2007, 04:09:46
However, after doing the "Check for updates" with Build 8679 (Opera 9.10), I still see this in my browser.js:
var bjsversion='edited: December 7, 2006, version: Opera 9.03 Desktop'
Thus, it seems that browser.js is not updating as it should.
By TreeGo, # 8. January 2007, 05:19:48
By quiris, # 8. January 2007, 06:30:49
By TreeGo, # 8. January 2007, 22:34:16
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.
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!)
Sorry, I can't help you with that. Might this help?
By hallvors, # 9. January 2007, 13:20:05
By jpvstaden, # 10. January 2007, 03:34:19