We have recently learned of yet another zero-day exploit in Adobe Acrobat. This time it's an overflow for a special type parameter in a function provided by the multimedia.api plugin that can be manipulated from JavaScript in the following manner: media.newPlayer(null) Somewhere deep in newPlayer, deinit_obj is set as the handler for deleting the object when it's no longer needed: And eventually deinit_obj calls the destroy function from the object's v_table: So far, so good, except the code wrongly assumes that validate_param function always returns, at which point it allocates the actual data for the object. Normally this is true, except when a special parameter is provided, for example, "null", in which case validate_param throws an exception. In this case, the player object remains half-initialized until later when it's no longer needed, at which point it will still try to call the destroy function. Unfortunately, doing so will redirect execution to an uncontrolled address, which in turn will crash the whole application. This technique alone is not enough for remote code execution as most of the time it will just crash at random addresses, depending on the data that was found in the heap, where the object should have been allocated. To achieve code execution, the attackers have employed other well-known techniques which we won't discuss here. Finally, this particular exploit seems to be stealthier than other Acrobat exploits we have seen, in the sense that it won't restart the whole application, thus not raising user's suspicion that something may have gone wrong. We've added a new detection, Bloodhound.Exploit.288 to detect attempts to exploit this vulnerability. Also worth mentioning, is the effort that an exploit writer will put forth in turning a seemingly unexploitable vulnerability into a working exploit. This is the work of a skilled programmer, not some script kiddie who found a proof of concept on an exploit site. Looking at the JavaScript from in-the-wild samples, we see evidence that the individual who developed the exploit is different from the individual or group that is actually using it. Comments left in the JavaScript seem to implicate less skilled attackers who forgot to cover their tracks: In the several samples we've gathered, detected as Trojan.Pidief.H and dated as early as November 20th, it seems that the attackers didn't even bother to modify the embedded shell code to suit their needs. All samples share the same shell code, which drops a 170-kilobyte (KB) executable as %Temp%\AdobeUpdater.exe and executes it, despite the fact that most of the variants of the dropped files need considerably less than the allocated 170KB. This is possibly further evidence of the flow of exploits from skilled reverse engineers who, rather than responsibly disclosing their findings, decide to sell the exploits on the black market, with step-by-step instructions for opportunists who would then attempt to profit from their use.