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.

  1. 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)
  2. Disabling javascript actually neuters the exploit this time, as this bug exists in the javascript module
  3. Analysis of the in the wild exploits and malware seem to indicate multiple people have this information and are using this to attack organizations.
  4. 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
  5. 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.