The Acrobat JavaScript Blocklist Framework
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2007-5659 | Buffer Overflow in Adobe Acrobat and Reader via Malicious PDF JavaScript Adobe Acrobat and Reader contain a buffer overflow (CWE-119) in their handling of arguments passed to JavaScript methods when rendering PDF files. An attacker triggers the flaw by convincing a user to open a crafted PDF whose embedded JavaScript calls methods with overly long arguments, and no user privileges beyond viewing the file are required. Successful exploitation allows a remote attacker to execute arbitrary code in the context of the user running Acrobat or Reader. Anyone running the affected Acrobat or Reader versions (specific version ranges are not provided in the source data) is affected, with Adobe Reader historically being one of the most widely deployed desktop applications. CISA added the vulnerability to the Known Exploited Vulnerabilities catalog on 2022-06-08, confirming exploitation in the wild, and EPSS assigns a 94% probability of exploitation within 30 days (100th percentile); no public proof-of-concept is known and ransomware use is unknown. Do: Apply updates per vendor instructions by upgrading Acrobat and Reader to the patched releases Adobe made available for your version line, and audit the estate for legacy, unpatched Acrobat/Reader installs given the 2022 KEV listing. As an interim mitigation, disable or restrict JavaScript in the Acrobat/Reader preferences and treat PDFs from untrusted sources (email attachments, drive-by download sites, exploit-kit delivery channels) with caution. | — | 94% | KEV |
| masshundreds of millions of users/installations historically (Adobe Reader/Acrobat is among the most widely deployed desktop PDF viewers); current unpatched… | |
| CVE-2008-2992 | Adobe Acrobat and Reader JavaScript Input Validation Flaw Enables Remote Code Execution Adobe Acrobat and Reader contain an input validation flaw (CWE-119, memory corruption) in a JavaScript method — historically the util.printf() JavaScript function — that fails to safely handle crafted arguments. An attacker triggers the flaw by getting a user to open a specially crafted PDF containing malicious JavaScript, which can corrupt memory and allow code execution on the victim's machine. Successful exploitation yields remote code execution with the privileges of the logged-in user, typically used to deliver malware; the related headlines indicate this flaw was folded into exploit kits and spam-driven malware campaigns of the era. Anyone running a vulnerable version of Adobe Acrobat or Reader (specific version ranges were not provided in the source data) with PDF JavaScript enabled is affected. Exploitation is confirmed in the wild: the flaw was added to CISA KEV on 2022-03-03 with known ransomware use, and EPSS assigns it a 98.5% probability of exploitation within 30 days. Do: Apply updated versions of Acrobat and Reader per Adobe's instructions, as required by the CISA KEV listing. As an interim mitigation, disable or restrict JavaScript in Acrobat/Reader preferences (a JavaScript blocklist/allowlist approach, consistent with Adobe's JavaScript Blocklist Framework), and caution users against opening unsolicited PDFs, since exploitation has occurred via exploit kits, spam campaigns, and ransomware delivery. Check endpoints for unpatched Acrobat/Reader installs and confirm remediation against the CISA KEV deadline. | — | 98% | KEV ransomware |
| massHundreds of millions of desktop users (an estimate | |
| CVE-2009-0927 | Stack-Based Buffer Overflow in Adobe Reader and Acrobat Enables Remote Code Execution CVE-2009-0927 is a stack-based buffer overflow (improper input validation, CWE-20) in Adobe Reader and Adobe Acrobat that allows remote attackers to execute arbitrary code on the victim's system. The flaw is triggered when the PDF handling code in these products processes malicious input, typically via a specially crafted PDF document delivered through email, the web, or exploit kits. Successful exploitation gives an attacker the ability to run arbitrary code, generally with the privileges of the user running the PDF application. Any user or endpoint running an affected version of Adobe Reader or Acrobat is exposed, and given the near-universal deployment of these PDF tools the potential population is very large. The vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog (added 2022-03-25) with a required action to apply vendor updates, and EPSS assigns a 96.6% probability of exploitation within 30 days, though no public proof-of-concept is known. Do: Apply updates per vendor instructions: upgrade all affected Adobe Reader and Acrobat installations to a patched release as required by the CISA KEV listing. As an interim mitigation, disable or restrict JavaScript in PDF files (the Acrobat JavaScript blocklist framework introduced around this period addresses this vector) and block PDFs from untrusted sources. Inventory endpoints for outdated Reader/Acrobat versions, prioritizing systems that open PDFs from email and the web. | — | 97% | KEV |
| masshundreds of millions of users (Adobe Reader was the dominant PDF viewer on desktops during the exploitation period) | |
| CVE-2009-4324 | Use-After-Free RCE in Adobe Acrobat and Reader via Crafted PDF Files CVE-2009-4324 is a use-after-free vulnerability in Adobe Acrobat and Adobe Reader in which a crafted PDF, typically using embedded JavaScript to invoke the media.newPlayer() multimedia API, frees an object that the program then reuses, corrupting memory. The flaw is triggered simply by opening the malicious PDF, so delivery as an email attachment or web download is enough, and successful exploitation gives an attacker arbitrary code execution with the rights of the logged-in user. Anyone running Acrobat or Reader versions current at the December 2009 disclosure was affected, which effectively meant the very large install base of the then-dominant PDF viewer, with observed attacks focused on Windows. The bug was exploited in the wild around the time of disclosure, with contemporaneous write-ups linking PDF-borne malware to Japan-earthquake-themed spam lures, and CISA added it to the Known Exploited Vulnerabilities catalog on 2022-06-08 (ransomware use: unknown). No standalone public proof-of-concept is catalogued, but EPSS ranks it in the 100th percentile with an approximately 82% probability of exploitation within 30 days, so defenders should treat it as actively exploited. Do: Upgrade Acrobat and Reader to the fixed release in Adobe's January 2010 security update (APSB10-02), per the KEV required action; the versions vulnerable at disclosure are long past end-of-life, so any current deployment is unsupported and should be migrated. As interim mitigation, block or strip JavaScript and multimedia actions in PDFs (for example via Adobe's JavaScript blocklist framework or gateway-level PDF sanitization) and treat unsolicited PDF attachments as untrusted. Hunt on legacy Windows hosts for signs of PDF-borne code execution following receipt of themed spam or unexpected PDF attachments. | — | 82% | KEV |
| massHundreds of millions of users at the time of disclosure (Adobe Reader's install base); residual unpatched legacy installs today likely in the hundreds of… |
Full article768 words · extracted from blog.talosintelligence.com · click to collapse
Wednesday, January 20, 2010 12:56
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\tBlackListThe 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.newplayerHow 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.getAnnotsAnd 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".
Text extracted automatically; images, tables and formatting may be missing. Original: https://blog.talosintelligence.com/acrobat-javascript-blacklist-framework/