Hey folks, Brad Arkin, Director, Product Security & Privacy for Adobe Systems left a note in the comments section of my blog entry on Vendor response (http://vrt-sourcefire.blogspot.com/2009/12/matts-guide-to-vendor-response.html). In that post, I expressed my concern on a number of issues related to Adobe Systems' response capability. Since most people who read that entry would not see the comment, I thought it fair to post Brad's response here. If you had forwarded the link of the original post, please do so again so Adobe's side of the story is heard. Brad Arkin's Comment Hi Matt, A couple correction regarding your JBIG2 timeline. Adobe learned of the bug on January 16, 2009 and issued the first patch for version 9 on Mac/Win platforms on March 10, 2009. Although this is a tighter range than you mention in your post, we certainly weren't satisfied with this response time. Our investments since then in improving patch turn around time allowed us to get three zero day patches out to users in around two weeks in April, July, and October. The ship schedule for the patch to the December bug was complicated by a variety of factors, not all of which were covered in the ComputerWorld article. My ASSET blog post provides some details here: http://blogs.adobe.com/asset/2009/12/background_on_reader_update_sh.html and a podcast I did with the Threatpost guys provides further insight into what went into the schedule decision: http://threatpost.com/en_us/blogs/brad-arkin-adobe-reader-zero-day-flaws-and-security-response-121709 Our goal in this incident and every incident is to help protect as many users as possible as quickly as possible against the threats that we are aware of. Happy to talk more if you are interested. I'm @bradarkin on twitter or you can get my mobile number from Matt W. if you'd like to talk on the phone. Thanks, Brad Arkin Director, Product Security & Privacy Adobe Systems Matt's Reply First: Brad, thanks for providing the corrections to the dates I used in my post. I'll update my material and, in the future, I will provide more accurate data. I have reviewed both your blog post and the podcast you referenced in your response. I strongly recommend that anyone reading this do the same. Brad fully lays out Adobe's reasoning for delaying the patch until the quarterly update there. The podcast is particularly informative, as Ryan Naraine did an excellent job of challenging Brad on several different fronts. That being said, I do want to say a couple of things after reading Brad's blog: Lets start on a positive note, let me say that I was very pleased to see the JavaScript Blocklisting functionality when you delivered it. We actually brought it up in the October 2009 Vulnerability Report (http://vrt-sourcefire.blogspot.com/2009/10/october-2009-vulnerability-report.html). I thought it was an excellent mitigation possibility for those organizations who simply couldn't do without Javascript. We've tested it here and it seems that, while it is unusually difficult to configure, it does do an excellent job of blocking those functions that it can (I am disappointed the we can't target unescape() though). Just remember that it is a mitigation only for those who have the infrastructure and expertise to use it. My real concern is that Adobe continues to make decisions and statements that some (me, for example) might read as indicating that either Adobe does not understand the impact that actively exploited vulnerabilities have on their customers or that Adobe simply does not place a great deal of value on that impact. Take, for example, this statement from Brad's blog: "Customer schedules - The next quarterly security update for Adobe Reader and Acrobat, scheduled for release on January 12, 2010, will address a number of security vulnerabilities that were responsibly disclosed to Adobe. We are eager to get fixes for these issues out to our users on schedule. Many organizations are in the process of preparing for the January 12, 2010 update. The delay an out-of-cycle security update would force on the regularly scheduled quarterly release represents a significant negative. Additionally, an informal poll we conducted indicated that most of the organizations we talked with were in favor of the second option to better align with their schedules." In reading that, all I can think is this: What "significant negative" could possibly justify delaying the roll-out of a patch that addresses an actively exploited vulnerability. With the exception of the Illustrator 0-day, which I also feel should be patched immediately, what is in Adobe's January 12th patch that approaches the severity of what is facing their customers right now? Clearly there is a benefit to reaching out to your larger customers, those who have the most momentum and infrastructure to manage, and working to understand their needs. But there are many, many people, companies and organizations who don't even have the ability to use Adobe's blocklist, don't have the expertise to understand the threat and don't have the budget to affect the decision making process of large software vendors. That set of people are utterly ignored in the decision making process that Adobe has laid out. I do want to end by saying I've seen significant improvement in Adobe's response to these types of issues. Don't let the fact that I have complaints about where Adobe is now lead you to believe I don't appreciate the improvements they've made. The difference between Adobe's response to the December 0-day and their ability to respond to the JBIG2 exploit clearly indicates that Adobe has put time, effort and money into improving their response capability. I anticipate continuing to see improvements in their ability to respond to rapidly developing threats. I also look forward to seeing improvements in the Adobe software set that will make it easier to update and manage. Brad, you can find me at kpyke on twitter (I'm now following you and I now see that you are following me (hi!)) and you (or anyone else) can hit me with my first initial and last name @sourcefire.com. Also, I'll probably drop you a call sometime later this week.