The number of so called 0day vulnerabilities seems to be on the rise and in response to this threat, a number of security researchers are pooling their skills to produce third party patches. There are plenty of arguments for why we're seeing this increase. Some would argue that it's due to improving skills of researchers coupled with a decrease in the quality of software. Others would suggest that an increasing profit motive for vulnerabilities that can lead to phishing attacks, spam propagation, etc. have drawn in a criminal element that is willing to put real human and capital resources behind the effort to uncover vulnerabilities. I would agree with the later argument. Suffice it to say, the good ol' days of patching just being a pain in the [expletive deleted] are long gone. You now have to make tough decisions about patching such as implementing less than desirable workarounds prior to a vendor patch being available or worse yet, taking a system offline. To top it off, you now have the option of implementing third party patches.

Third party patches aren't new but they've hit the media spotlight recently thanks to the emergence of the Zeroday Emergency Response Team. ZERT is a collection of some of the best and brightest reverse engineers in the security industry who are working together to produce "a non-vendor patch when a so-called "0day" (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the Internet or both". ZERT came into existence when it released a patch (ZERT2006-01) for the recent Internet Explorer VML vulnerability (MS06-055). The patch was withdrawn once the Microsoft patch became available and a revised ZERT patch was then released for now unsupported versions of Microsoft operating systems. On September 30, ZERT acted again by releasing ZProtector as a patch for a buffer overflow in the Microsoft WebViewFolderIcon ActiveX control (CVE-2006-3730) which remains unpatched as of this posting. Alexander Sotirov of Determina had also publicly released a patch for this same vulnerability a couple of days earlier. This isn't the first time that Determina has publicly released a third party patch. They took the same actions when the Internet Explorer createTextRange() vulnerability was being exploited in March 2006. Others such as eEye and Ilfak Guilfanov have also released patches for 0day vulnerabilities in the past.

While, researchers seem willing to step forward to apply their expertise to produce such patches, I predict that applying said patches will remain the exception as opposed to the rule for a few reasons.

What will prevent third party patches from gaining acceptance?

1. Trust - The average user does not have the skills to determine the overall effect of implementing a patch. Will it work? Will it negatively impact other functionality? Will it install spyware on my machine? These are questions that should be asked any time software is installed on a machine, regardless of whether that software comes from a reputable software vendor or a third party. In the end, for the average user, installing software is a matter of trust. They have no idea what the software will truly do so they simply trust the supplier. In general, people have far too much trust when it comes to installing software as can be seen by the success of adware and spyware. However, I do not expect that most end users or system administrators will be willing to place that same trust in a third party patch when they vendor patch is (hopefully) on it's way.
2. Liability - Applying a third party patch is like making a modification to a new kitchen appliance - it voids the warranty. Perhaps only figuratively given that no one is suing software vendors when they are compromised due to a vulnerability in a commercial application but it does put pressure on those responsible for patching in a corporate environment. What if I implement this patch and something goes wrong? If the vendor patch is bad, I can blame the vendor and people will accept the argument. If the third party patch fails, who do I blame?
3. Effort - As with applying a workaround, applying a third party patch, increases the level of effort. It is a temporary fix that must be undone when the vendor patch ultimately arrives. This may be trivial for a single machine but can result in significant cost for a large corporation. In my experience, corporations are rarely willing to implement workarounds, especially when they involve touching individual desktops.

If there are so many downsides to third party patches, is this a valuable effort? Producing and testing such a patch is a time consuming task that requires specialized skills. Why do it if few people will be willing to install it? Personally, I feel that the efforts made by ZERT, Determina and others have a significant benefit that goes well beyond the patch itself. The fact that third party researchers, with no access to source code, can develop an effective patch through reverse engineering in less time than the affected software vendor puts a great deal of public pressure on the vendor to act more quickly.

My greatest complaint of vendors when it comes to producing patches is the amount of time that will lapse from the time that they are informed to the time that a patch is publicly released. In my previous role with iDefense managing their VCP program, I spent much of my time working with vendors reporting vulnerabilities and negotiating disclosure timelines. To be fair, a vendor has a much more significant obligation when it comes to conducting regression testing to ensure that a patch works properly on all systems than would a group of third party researchers but in general, the patch process takes far longer than it should. I have been involved in far too many vulnerability reports where the patch timeline was measured in years as opposed to months or preferably weeks. At the same time, vendors have demonstrated that they can push patches out quickly when they must. Microsoft has done an admirable job of pushing out of cycle patches when they deem the overall risk of a 0day attack to be high enough. In 2006, they have released two out of cycle patches thus far. The first ZERT patch (ZERT2006-01) was released on Sept. 22, while Microsoft released their patch four days later on Sept. 26. Did the availability of a third party patch influence the release date of the Microsoft patch? I don't expect that we'll ever know, but I suspect that it was a hotly debated topic around the boardroom table. In fact, both of the Microsoft out of cycle patches this year were proceeded by third party patches. I applaud those willing to put in the time and effort to produce these patches. The true value of third party patches lies in a couple of areas. One benefit is that they provide patching alternatives for unsupported versions of vendor software. However, the greatest value by far is the pressure that such patches place on vendors to remediate vulnerabilities in a timely fashion. Third party researchers producing patches shouldn't measure their success by the number of downloads for their patch, they should measure it by the shrinking timelines for patches released by the vendor.

- michael