Adobe/Acrobat 0-day in the wild?

Published: 2009-02-20
Last Updated: 2009-02-23 03:03:09 UTC
by Joel Esler (Version: 7)
7 comment(s)

According to our friends over at Shadowserver, There is a new Acrobat 0-day in the wild.  They say you can avoid it by turning off Javascript inside of your Adobe Acrobat products. 

Please see Shadowserver's write up: here for more information

UPDATE:  Another great VRT Blog post.  These guys keep pumping them out!  Check it out here.

UPDATE  Shadowserver has released important mitigation information.  You can see that post at the url below.

http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090221

UPDATE:  Sourcefire VRT has published a "homebrew" patch for the vuln.  PLEASE TEST THIS BEFORE DEPLOYING IN ANY ENVIRONMENT!!!  SANS ISC has NOT verified the effectiveness of this "homebrew patch", and as such we cannot make any claims or comments on its effectiveness or any unintended consequences of using this modified software.  As some of you may remember ZERT in the past has done similar, and there are obviously caveats involved with this approach. (both technical and possibly legal) So please do educate your self, and if need be discuss with your legal team before deploying third party modified software into your environment.

Information on patch:

http://vrt-sourcefire.blogspot.com/2009/02/homebrew-patch-for-adobe-acroreader-9.html

Information on ZERT:

http://www.isotf.org/zert/

Disclosure:  Joel works for Sourcefire, but does not work for the VRT.

UPDATE 2:  Based on the comments to this diary entry something needs to be cearly stated. Java has NO relation to this exploit, javascript is utilized by the attackers to massage memory structures to build a more reliable exploit.  Disabling javascript will remove this ability and make a reliable exploit much harder to build.  - Andre L

-- Joel Esler http://www.joelesler.net

-- Andre L

Keywords:
7 comment(s)

Comments

Can hardly believe an Adobe patch will be out for this exploit March 11th, that's almost 3 weeks!

Excuse my french - wtf...!
Yeah, but then again it's a Java problem, and anything Java=related is notoriously slow ;-)
It's not really a JAVA problem.
In this specific case it is, but, as far as i understand, JAVA is not needed to exploit the mentioned issue.
So other working exploits will come up, not using JAVA, but getting a lot of users into trouble.
\"Friends\" at ShadowServer???

And you should really disclose relationships before you brag up VRT.
Relationships? Like, \"Hey, I work for Sourcefire\"?
java has nothing to do with this exploit or the mechanics of the exploits floating around. Attackers are using javaSCRIPT to massage the heap to allow for more reliable exploitation. Disabling that removes that capability from their tool chest, and that in turn makes the exploit much much harder to accomplish.
I found this nugget of joy on the VRT blog especially disturbing. "Oh, by the way, I forgot to mention. If you happen to open an explorer window, or a browser window, or anything at all that even has the ICON of the pdf file, you're owned." This may be a silly comment but is disabling JS really going to help that much. It will simply ask them if they want to re-enable. They will say yes and be owned anyway.

Diary Archives