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 Motoman on 12/29/2008 1:08:38 PM , Rating: 2
...I just have to say that, when talking to corporate customers who ask why a new release didn't hit it's target date, I always tell them that "we're sorry we didn't release it when we thought we would, but we'd much rather miss a target date than put out code we know isn't working right."

That just flat-out makes sense. Whether it's a patch or a full release, I think it's a really bad idea to fling it out the door without an adequate amount of testing. Much less to release it to the wild with bugs you know are in there, just to hit your date. In all cases I would always prefer to get a customer a little miffed at me for missing a date and making them wait a little while longer than shipping them dodgy code that screws up their systems.

By TomZ on 12/29/2008 1:18:45 PM , Rating: 2
I agree, but you have to see this for what it is: the inability to successfully predict the outcome of the software development process. This tells me that we have more work to do in terms of learning how to manage software development in the industry in general.

By haukionkannel on 12/29/2008 3:36:55 PM , Rating: 2
IE is so defacto browser, that when MS does an patch, it has to be sure, that people still can goto to the net bank etc... Smaller browsers can do a ghanges quiker, because if something does not work, the solution comes quickly and in mean time you can use IE...
So it's big dilemma. For me the solution would be, that IE would not be so integral part of Windows, and every corporate and public web service would be tested for at least 3 different browsers. So when one is upgraded, at leat two will work properly... But this will newer happen in the word of IE dominant. It's "too expensive" to make aplications to work with different browsers...
Well actually there is solution even to this... Stardardised HTML... but as long as IE does not use it... Well you know how it is... If every internet page would be tested to work with standard HTML, any browser that is made to work with this standard would work, and having any two independed browser in you OS would allow the use of every aplication in the net even after very quick update.

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.

"Spreading the rumors, it's very easy because the people who write about Apple want that story, and you can claim its credible because you spoke to someone at Apple." -- Investment guru Jim Cramer

Most Popular Articles5 Cases for iPhone 7 and 7 iPhone Plus
September 18, 2016, 10:08 AM
Automaker Porsche may expand range of Panamera Coupe design.
September 18, 2016, 11:00 AM
Walmart may get "Robot Shopping Carts?"
September 17, 2016, 6:01 AM
No More Turtlenecks - Try Snakables
September 19, 2016, 7:44 AM
ADHD Diagnosis and Treatment in Children: Problem or Paranoia?
September 19, 2016, 5:30 AM

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