Does the Patch Development Process Need a Patch?

Last Thursday, Microsoft released a patch to correct a problem with Windows Metafile Format (WMF) files. There's been plenty of speculation as to just how bad the problem might actually be on unpatched systems.

Some prominent individuals accused others of exaggerating the risks. I think the real sticking points for those who expressed extreme concern about the dangers were that the vulnerability affects a vast number of systems--nearly every Windows system in use today--and that the vulnerability is very easy to exploit. Fortunately for everyone, the WMF vulnerability isn't something that can be directly exploited via a worm. Exploits must rely on some amount of user interaction or other vulnerabilities to propagate.

One interesting aspect of the ordeal to date is how quickly Microsoft produced a comprehensive patch. The company said that the patch had to be tested on many different systems running various Windows versions in 23 languages. Microsoft also said that the turnaround time of basically two weeks was a company record for the production of a comprehensive (i.e., not temporary) security patch.

In many cases, Microsoft has taken many months to release a patch after a security problem has been reported to the company. It's not unusual for problems to remain unpatched for the better part of a year. If Microsoft could produce the WMF patch so quickly, why can't the company produce all security patches in such an expedited manner?

Some security problems are more difficult to correct than others. In difficult cases, the engineering involved is complex and could require a lot of time. People have pointed out that turnaround time on patches also appears to involve other factors, such as the number of systems affected and the severity of risk as judged by Microsoft.

Some state that they'd rather have a stable patch than a faulty patch. But when the timetable slips beyond what the vulnerability discoverer thinks is reasonable, then he or she might eventually publish the exploit "in the interest of full disclosure." This action forces vendors such as Microsoft to immediately shift priorities to address the problem more quickly, but at the same time alerts intruders to another inroad.

One possible way to shorten security patch turnaround time is for Microsoft and other vendors to publish beta copies of their security patches as they do for other software. One might think that if they make the security patch process open to public beta testers, the turnaround time could be reduced significantly. But releasing a beta security patch is essentially the equivalent of prematurely disclosing the nature of the vulnerability, which most vendors are loathe to do. It would be relatively easy for some people to reverse-engineer the patch to find the problem the patch is intended to correct. That of course could lead to increased risk for innocent people when the patch isn't widely available. It seems clear that public beta testing of security patches isn't such a good idea.

Many people think that vendors should consistently place the highest priority on correcting security problems in their respective products. In some cases, vendors do seem to place a priority on security fixes with reasonable consistency. But in other cases, a vendor's priorities are flexible based on their own perception of any associated risks. As was made clear yet again with the WMF vulnerability, interpretation of the risk level of a given vulnerability often varies among experts. Resolution of such differences of opinion isn't likely.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.