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

RE: Pre-patch fix?
By omnicronx on 12/29/2008 2:12:31 PM , Rating: 2
Half the time these fixes only require very small code changes. I wonder if they can merely re-release a patch to undo what the previous one did, and fix it properly. This would be the best of both worlds.


RE: Pre-patch fix?
By TomZ on 12/29/2008 2:31:33 PM , Rating: 2
That doesn't really solve the problem, however, which is that a released patch might cause other problems like stability or compatibility issues.

A better approach I think is for these companies to dedicate more staff to fixing and testing these types of patches. That way you can have your cake and eat it too. Microsoft's sales last FY were over $60B - somehow I think they can find enough budget to release patches that are both timely and well-tested at the same time.

That said, I think some of the criticism being made against Microsoft and some of the others in terms of releasing patches too slowly is a bit unfounded. What is important is that patches are widely deployed before they are abused which seems to be happening in most cases.


RE: Pre-patch fix?
By omnicronx on 12/29/2008 2:49:56 PM , Rating: 2
MS does usually wait until their patches have been thoroughly tested, but in cases such as last weeks IE7 vulnerability, I would rather a patch with a few issues, than no patch at all for a week. When a huge percentage of systems worldwide are affected, patches are required immediately regardless of the consequences. We are talking Billions of dollars in potential losses compared to a few headaches here and there.

I do think a better system is needed though.


RE: Pre-patch fix?
By TomZ on 12/29/2008 2:56:37 PM , Rating: 2
quote:
We are talking Billions of dollars in potential losses compared to a few headaches here and there.

That statement could go either way - right? In other words, billions of dollars in potential losses due to a mistake made in a patch compared with a few security headaches here and there.

Microsoft rightly knows it has to be careful with patches. There is a lot at stake on both sides - releasing too soon or too late.


RE: Pre-patch fix?
By omnicronx on 12/29/2008 2:58:14 PM , Rating: 2
Very true. Kind of a double edged sword though isnt it? Damned if they do, damned if they don't.


RE: Pre-patch fix?
By Mitch101 on 12/29/2008 3:26:52 PM , Rating: 2
Sandboxie
http://www.sandboxie.com/

Sandboxie runs your programs in an isolated space which prevents them from making permanent changes to other programs and data in your computer.


RE: Pre-patch fix?
By TomZ on 12/29/2008 9:33:41 PM , Rating: 2
Do you think that will somehow help with OS patches?


RE: Pre-patch fix?
By MrDiSante on 12/30/2008 1:43:45 AM , Rating: 2
I agree with TomZ's post above and would like to add that it's called "leaving UAC on". It doesn't completely sandbox, but it does do a good job for protecting IE, which is the biggest trouble-maker. As well, it makes sure that only your account gets trashed in case someone does exploit your system.

Second of all, for the most part I find that Microsoft seems to get it just about right with patches. I would prefer that the occasional critical flaw get patched out-of-cycle and in a more rushed manner than usual, but aside from that they tend to find the flaws before the go zero-day.


RE: Pre-patch fix?
By Mitch101 on 12/30/2008 8:03:46 AM , Rating: 1
A lot of people in here are anti-Vista for one reason or another and boxie is a good solution for them.

As for patching we all know we want the patch sooner than later. Patching really only happens when the exploit is known. In the time before it is a known or documented issue someone may have been using the exploit for some time.

I recommend boxie because its a bit simpler than running another OS within a VM. If you shut down without saving the changes any exploit that may have been applied to your VM would be gone the next time you fire up the VM.


RE: Pre-patch fix?
By tastyratz on 12/29/2008 3:34:06 PM , Rating: 2
I actually really like the idea suggested earlier, that they have updates similar to an AV program. Security patches are a necessary thing and I think Microsoft's is still too slow to market. I think they are so afraid of the press for doing it wrong that they wont release it until they know its perfect. Very rarely do you see a newer revision of a patch pushed out. I think Microsoft should offer opt in preliminary patches. These would have elementary levels of testing and refinement (between beta to rtm - not alpha quality) but are sent out quick to market. They can focus on revised patches going out once available. This would allow them to have their cake and eat it too. People who require the stable revision of patches can wait but people who want a quick fix right away can be satisfied as well.

I also think they should ditch the standard usual patch release schedule. Trickle them out as they are made, don't just release them in batches to be convenient. If the person needs convenient they can install them in batches (or sys admin only release them in batches)


"Game reviewers fought each other to write the most glowing coverage possible for the powerhouse Sony, MS systems. Reviewers flipped coins to see who would review the Nintendo Wii. The losers got stuck with the job." -- Andy Marken














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