backtop


Print 30 comment(s) - last by foolsgambit11.. on Dec 30 at 5:14 PM

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


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

By foolsgambit11 on 12/29/2008 6:12:34 PM , Rating: 2
Yes, that absolutely makes sense when a business is currently waiting for a new release, but can conduct their business safely with their current software (or lack of software). But with security patches, it's different. Waiting to get things right then must be weighed against the risks taken on by not waiting. Since both sets of risks are intangible and immeasurable, it's not an easy decision.

So instead of imagining a customer miffed that they didn't get their code when they wanted to, imagine that they're miffed because, after waiting a week for a patch to a known vulnerability, they are hacked and have their private data stolen. Okay, miffed isn't the right word for that case. But you get my point.

The debate of how to release patches isn't new, and isn't about to be solved any time soon. It's more a matter of security philosophy than security best practices. Because it's pretty much impossible to tell which practice is best in many cases.


By Motoman on 12/30/2008 12:50:20 PM , Rating: 2
The problem boils down to whether you're sure you're fixing the problem, or if you might be making it worse. Rushing a patch out the door without having done adequate testing is leaving yourself vulnerable to introducing new bugs.

While I certainly understand that a high-profile bug has to be patched ASAP, you have a certain amount of due diligence to go through before you can ship a patch to fix it.


By foolsgambit11 on 12/30/2008 5:12:25 PM , Rating: 2
Absolutely agree. But how much is that 'certain amount of due diligence'? Different companies may see it somewhat differently. Both the company that made the software and the company or companies that use(s) the software may evaluate the risk differently. So, as a company, you should evaluate whether you prefer Mozilla's or Microsoft's (or Apple's, or anyone else's) update methodology from a security standpoint. And pick the product that shares your risk philosophy. Neither philosophy necessarily is riskier, because it's hard to evaluate whether the risk of patching or not patching right away is greater in many cases. Critical vulnerabilities being the exception.


"This is from the DailyTech.com. It's a science website." -- Rush Limbaugh














botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki