Diary

 

Adobe/Acrobat 0-day in the wild?
Share |
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...!
posted by Brian, Fri Feb 20 2009, 19:07
Yeah, but then again it's a Java problem, and anything Java=related is notoriously slow ;-)
posted by Lee, Fri Feb 20 2009, 21:17
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.
posted by Manuel, Sat Feb 21 2009, 10:06
\"Friends\" at ShadowServer???

And you should really disclose relationships before you brag up VRT.
posted by Ken, Sat Feb 21 2009, 15:02
Relationships? Like, \"Hey, I work for Sourcefire\"?
posted by Joel, Sun Feb 22 2009, 21:46
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.
posted by Andre, Mon Feb 23 2009, 00:03
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.
posted by Jason, Mon Feb 23 2009, 19:11
Login here to post a comment. Diary Archive