Adobe Reader media.newPlayer() Analysis (CVE-2009
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| 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 article504 words · extracted from blog.talosintelligence.com · click to collapse
Adobe Reader media.newPlayer() Analysis (CVE-2009-4324)
Tuesday, December 15, 2009 18:53
First off its not Friday, and hopefully you'll have a better weekend. The reason for that is you are set with rules and clam sigs.
Now what the heck am I talking about….
Last night Adobe released an advisory detailing an in the wild exploit for Adobe Acrobat that is currently circulating in a number of places. Due to all the confusion and hype last time around with the famous JBIG2 vulnerability we figured we'd take a deep dive into the specifics surrounding this vulnerability so everyone can better understand what it is doing and how to protect yourself against it.
First off the executive summary for those who don't have a lot of time.
- The in the wild exploit is detected by both our Snort signatures and the ClamAV signatures (SIDs 16333 and 16334, ClamAV Exploit.PDF-4619 and Exploit.PDF-4620)
- Disabling javascript actually neuters the exploit this time, as this bug exists in the javascript module
- Analysis of the in the wild exploits and malware seem to indicate multiple people have this information and are using this to attack organizations.
- The following sites have additional information on the attack: http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20091214
http://extraexploit.blogspot.com/search/label/CVE-2009-4324 - Enabling DEP will stop the in the wild samples we've seen, but is not fool proof
If you're interested in the details of the bug to better defend yourself and recognize samples, here are the basics. The bug is contained in the doc.media object and is triggered when sending a null argument to the newPlayer() method like so.
try {this.media.newPlayer(null);} catch(e) {}If I had to guess, I'd say this makes use of a vtable pointer that hasn't been initialized, due to a use after free issue. The sample in the wild makes use of util.printd to create an object of the same size as the media object, which is allocated to the same spot. Then, when the vtable is loaded, the data from the printd is used instead. The printd is what is used in the wild, but probably isn't the only way to get here.
Basic detection can be developed from the following:
try {this.media.newPlayer(null);} catch(e) {}util.printd("12345678901234567890123456 : 1231234", new Date());Luckily, the attacker assumes that this is enough to get reliable execution, however, if there are chunks in the lookaside list of that size, they might be used for the printd space rather than the addresses the attacker requires to be here. We have not seen any in the wild samples that compensate for this problem.
Once the vtable is controlled, it is possible to make use of a standard javascript heapspray to ensure that the pointer you control goes somewhere useful. Currently, this approach does not work on machines with DEP on, however there are techniques to circumvent it.
From the number of blogs and other messages we've seen surrounding this issue, we know a lot of people have the samples and are actively working on both protections and exploits for this vulnerability. This is something to tend to immediately.
Text extracted automatically; images, tables and formatting may be missing. Original: https://blog.talosintelligence.com/adobe-reader-medianewplayer-analysis/