The genesis of this article started with the observation that the time lag between the discovery of a security issue in a product and the (hopefully) eventual release by the vendor of a fix is highly variable. Some reasons for that variability, and in particular, why that lag may seem long is the topic of this discussion. I'll try to stay on track, but may occasionally veer off to observe interesting stuff (at least to me) along the way.
I should point out that my perspective is that of the vendor of a product and not that of a security researcher.
Not too long ago an email made its way to many of the security mailing lists with this topic:
Multiple Vendor libexif Integer Overflow Heap Corruption Vulnerability iDefense Security Advisory 06.13.07 http://labs.idefense.com/intelligence/vulnerabilities/
It discusses a problem with parsing Exif data, used in most digital cameras, and in most software shipped by manufacturers of software with those cameras. In this case the library is open source. Now here's the relevant part:
VIII. DISCLOSURE TIMELINE08/16/2006 Initial vendor notification
06/05/2007 Second vendor notification
06/11/2007 Initial vendor response
06/13/2007 Coordinated public disclosure
Ten months went by between the first notice to the vendor and the second notice. The second notice seems to have gotten some attention, and only a few days later the public disclosure occurred. But TEN MONTHS? Why didn't the security researcher ping the vendor sooner than ten months after the first disclosure? Did the vendor miss the first notification? If not, what were they doing in the interval?
Speaking of intervals, remember the news regarding bike locks and pens back in 2004?
http://www.wired.com/culture/lifestyle/news/2004/09/64987
Note this part of the article:
"The lock's flaw was apparently first publicized in 1992 in the United Kingdom... The BBC even covered it, but the news apparently didn't resurface until a dozen years later."
Talk about lag time. You can still buy locks that are way too easy to open, but that's a different topic for another time.
Back to software. Now, I was not a party to any of this, but let's posit a hypothetical that instead of an open source vendor of this library, the vendor was a commercial supplier. They supplied this library to many vendors who used it in software that eventually made its way to consumers. Let's look at the various channels that software might follow to get to the consumer, and consider what time lags are built into each channel. We may find where those ten months went.
When you buy a digital camera most often you find a CD in the box that contains some sort of image processing software. You may find a version of Adobe Photoshop Elements, you may find a proprietary software package, and you may find both. That CD was made in bulk months before the camera was purchased, inserted into the box on an assembly line overseas, and shipped to a warehouse somewhere in the world. It could easily have sat on a shelf, either in the warehouse or in a retail store, for a year or two before being purchased. That's one channel, and we can see a few issues already.
The CD needs to be remastered, at least for new production runs. The original developer of the software needs to integrate the fixed library into the software, do their QA, provide a new master copy of the software to the camera company, which then would presumably also need to go through QA or acceptance testing, a build cycle for the new CD, and so on. They might need to decide on what info they supply to registered users of the software regarding this security issue. Do they host a patch or update on their web site (more QA)? How many languages does the notice need to be translated into? What training, if any, needs to be given to call center employees (and yes, there will be calls if they post or mail or email a notice). This leaves out the question of product recalls and such.
It gets better. Let's consider another channel. In this case the image software is pre-installed on the hard drives of a major retailer of consumer computers. Yup, another set of QA cycles, new builds of a gold master hard drive image to install on computers at the factory or factories, and the same set of questions regarding disclosure/notice to consumers who purchased a computer with this software pre-installed. Plus all the issues of FAQs on a web site, call center training, notice translations, product recalls, and so on.
One of the interesting things about the libexif advisory above is that none of the final products that incorporate the library are disclosed. The closest to that degree of disclosure is this statement:
Exploitation requires that a targeted user process a malicious image using one of several available tools that utilize libexif for Exif tag parsing. These tools include, but are not limited to, several applications included in the GNOME and KDE desktops.
Now imagine the discussions, negotiations, politics and such that would have gone on in our hypothetical case above with a commercial supplier and a security researcher who had found the vulnerability in just one of the many commercial products that incorporated it. Should the supplier of the library disclose their full customer list? In fact, they may be contractually prohibited from doing so. Clearly they need to contact all their customers, but during that TEN MONTH lag perhaps the researcher finds other applications that have incorporate the library. The list of affected application shifts over time, and getting agreement from each final customer on the wording of disclosures becomes a major effort. What's that you say, why should the wording be negotiated? Why should the end customer have input, be involved? Remember that the end customer may need to create web FAQs, emails, or paper mail that discusses the issue, and consistency of messaging is important. Remember, this stuff is being translated into a dozen or more languages, approved by product line managers in many countries, and coordinated with PR agencies.
Who pays for the costs of the mitigations listed above? New software builds, testing, new masters, translations, call center training. The costs rapidly exceed the revenue the library supplier generates from sales of the library. What do the contracts say with respect to responsibility? Who considered this scenario when the contracts were drafted?
Now, some of the issues above could be addressed by smart programming. Producing software that can be updated auto magically via the Internet would help. Having a feature that periodically checks with the mothership for those updates would help (do it right or you've got another security risk). None of this changes the issues of coordinated release, call center training, and so on. Nor does it remove the issues of remastering CDs and gold hard drive images.
Now I'm not advocating that vendors go dark for months at a time to deal with their internal and customer issues. Far better to communicate quickly, directly, and honestly with security researchers about the time needed to resolve vulnerabilities, not just from the code perspective but from the downstream customer perspective as well. This communication needs to be persistent and continuous, setting appropriate expectations on both sides. This may not change the time between discovery and disclosure but it will improve the relationships between security researchers and the vendors they research.