Is hurrying a patch the right answer when it could compromise quality?

Mozilla representatives sharply rebuked a report earlier this month which pointed to Firefox as being the "most vulnerable app" to businesses. In its rebuke, Mozilla cited its rapid rate of patching and criticized Microsoft as being too slow when it came to patches, particularly for Internet Explorer. The result is an interesting debate -- should patches be rushed to market or be given time to be fully tested.

Blog site Cheap Hack offers an insightful analysis of this issue. Observing the Mozilla/Bit9 squabble, it notes that Mozilla has had a couple major problems arising possibly from rushed patches. One patch for Firefox earlier this year introduced a stability problem. Another batch of patches in an update left off an important Firefox 2 patch, though Mozilla maintains that this was an "administrative error", not an omission due to the rushed rate of patches.

On the other hand, Mozilla's patches do indeed hit the market faster. This may lead to a lower security risk for its customers.

The real dilemma for companies like Mozilla and Microsoft when it comes to patching is the question of how much time to devote to thorough testing. Typically, a security flaw such as the recent major vulnerability found in Microsoft's Internet Explorer, can be analyzed and a patch created with only a couple of days. However, testing the patch and its implications to overall functionality is much harder.

For Mozilla, which has leaned towards leaner testing, at times falling short in this department, this is a trouble spot. For Microsoft, this issue is perhaps even tougher as it is the industry leader and has a much greater business market share, thus its moves are scrutinized to a greater extent. Microsoft must test its patches with a multitude of Windows configurations and look for compatibility issues.

Another problem arises in cases such as the WMF code in Windows GDI, where quick patching can ignore a broader architecture problem which yields more similar undiscovered flaws. A great deal of time can be wasted creating very similar patches, while missing that the patches are all caused by the same underlying issue. In the case of the WMF code multiple patches were released that were remarkably similar. And while a fix-all systematic solution might not be possible in this case, Microsoft may have failed to check into it in an effort to roll out patches faster.

When it comes to hurried patches, Mozilla may indeed be more troubled than Microsoft. However, another issue is when patches arrive far too slow. For example, an SQL bug in some version of Microsoft's SQL projects has existed known and unpatched since April. Microsoft may have wanted to include the patch in a service pack, but it should have acted far sooner, when an appropriate bundle failed to come along.

The latter extreme -- patching far too slow -- is an especially big problem for Apple. Apple systems have traditionally been rarely targeted by hackers and malware writers, however, the machines are beginning to have more problems with malicious assaults. This has led Apple to urge its users to get antivirus protection. However, Apple's leisurely pace of patching in its programs such as Safari, something it attributes to thorough testing, may place its users in danger. Apple has at times been praised for thoroughly testing its patches. However, no antivirus program can safeguard users entirely on a poorly patched system, and its slow patching may do more harm than good.

In all patching philosophies differ dramatically by company. Mozilla features an ultra-quick patching cycle, while Apple features an extremely slow one. Microsoft falls somewhere in the middle; a little more towards the slow end. In the end the debate over how much time to allow between security flaw discoveries and patch releases remains a tricky question unlikely to be solved in the near future.

Comments

Threshold

Username

Password

remember me

This article is over a month old, voting and posting comments is disabled

They recently implemented such a thing. I sit on a comity every month to analyze MS patches. They added an index (I forget it's name) that says how either it's unlikely to be exploited, likely to be exploited or is exploited. It's very basic but add it to all the available information, and you know if something is being attacked or not. I remember a stat saying that my employer was targeted thousands of times a day and not a single breach from it. It used to happens (Code Red?) and they fix the process issues.