Adobe recently announced and released the Adobe Reader and Acrobat JavaScript Blocklist Framework. I've had a little bit of time to play with it and would just like to share my thoughts. First of all, I am very pleased with this new blocklisting feature. Until now, when we knew about 0-day being actively exploited in the wild using JavaScript in some manner, we would just turn off JavaScript in Adobe products (Reader, Acrobat, etc...) all together. Personally, I could live without having JavaScript in my documents, but that's a totally different discussion. I understand why some people might want that feature for their PDF documents and why for them at least, turning JavaScript completely off would not be an option. So let's say, for example, that you are running Adobe Reader 9.2.0 which is vulnerable to the DocMedia.newPlayer JavaScript API bug. You decide that it is in your best interest not to allow that method from ever executing. How would you go about blocking that? The official document put out by Adobe says: the "JavaScript Blocklist can be in two locations" on a 32-bit Windows system:

- HKLM\SOFTWARE\Adobe\<product>\<version>\JavaScriptPerms\tBlackListand- HKLM\SOFTWARE\Policies\Adobe\<product>\<version>\FeatureLockDown\cJavaScriptPerms\tBlackList

The first key is "modified by Acrobat and Adobe Reader patches whenever an API is deemed vulnerable" (this feature is currently in testing with a select group of beta testers). I decided to modify the second registry key. The manual configuration of this registry key was tricky since...it did not exist on my system with Adobe 9.2.0 installed. Thankfully it's not hard to create a registry key, and I did just that. Note that everything you type is case-sensitive when it comes to the registry keys related to the blocklist, from the value name to the values themselves. I spent a ridiculous amount of time trying to figure out why the blocklist wasn't working. It was because I had manually created a key called tBlacklist instead of tBlackList. Now came the time to test the effectiveness of the blocklist. I entered the Javascript API function docmedia.newplayer in the registry as indicated in the document by Adobe. I typed in:

docmedia.newplayer

How to verify if I had typed it in correctly? There was obviously no confirmation that I had blocklisted docmedia.newplayer. I went through the options of Adobe Reader and nowhere was there a mention that docmedia.newplayer was blocklisted. What was I going to do to next? Wait until I received a PDF that had code to exploit the vulnerability to see if the blocklist worked as it was supposed to? I decided to create a simple, harmless PDF that invoked that function to see if the API call would get blocked. I could successfully open the file without the function being blocked. This time, I quickly pinpointed the reason for that: API functions are case-sensitive and entering docmedia.newplayer is not the same as entering DocMedia.newPlayer. My concern was then that obfuscation techniques in Javascript could fool and circumvent the blocklist blocking. I tried basic evasions techniques:

  • obfuscation function names, function contents
  • lexical transformation
  • control transformation
  • data transformation (data structure) There was no fooling Adobe Reader into executing the blocked function. It seems like Adobe Reader is hooking the function calls and is not going through the code trying to perform a string match. As of today, there isn't an official list of Adobe Javascript API functions to block, but I'd suggest adding the following to your blocklist just because these functions have been heavily exploited in the past several months: Util.printf (CVE-2008-2992) Collab.getIcon (CVE-2009-0927) Spell.customDictionaryOpen (CVE-2009-1493) Doc.syncAnnotScan (CVE-2009-2990) Doc.getAnnots (CVE-2009-1492) DocMedia.newPlayer (CVE-2009-4324) Very often, malware will escape Javascript code in order to avoid detection. The code is unescaped and evaluated at runtime. Therefore, these two function are commonly seen in malware and usually used one right after the other:
unescape()eval()

Unfortunately, these functions cannot be blocklisted through the Acrobat Javascript Blocklist Framework. Maybe it's just because they aren't, per se, Adobe Javascript API functions? We would love to be able to do that in the future, though. I also wanted to blocklist these two function because they have been exploited in the past:

app.CheckForUpdate (CVE-2008-2042)Collab.collectEmailInfo (CVE-2007-5659)

Turns out these are unpublicized Adobe Javascript functions and perhaps because of their nature, cannot be blocklisted. Finally, here's the blocklist that I propose, should you want to use it:

Collab.getIcon|DocMedia.newPlayer|Util.printf|Spell.customDictionaryOpen|Doc.syncAnnotScan|Doc.getAnnots

And here are simple harmless PDF files to test the implementation of your blocklist. Upon the functions being successfully blocked, you will see a yellow bar displaying "A JavaScript that this document uses is disabled for security reasons".