Another Black Eye for Microsoft Patch Creation Process

 
 
By Ryan Naraine  |  Posted 2005-10-28 Email Print this article Print
 
 
 
 
 
 
 

Updated: Security researchers highlight more errors in Microsoft's patch creation process and warn that the mistakes are proving costly for users.

Its being called the "story of a dumb patch."

A private security research firm has published an advisory with details on a fundamental mistake made by Microsoft Corp. that caused a security patch to ship without an adequate fix for the flaw it was meant to address.

Cesar Cerrudo, founder and CEO of Argeniss Information Security, found that the inadequate fix was included in the MS05-018 bulletin that shipped on April 12, leading to a situation where a new patch had to be created to provide comprehensive protection.

Cerrudo, a well-known researcher who specializes in application security, published technical details, here in PDF form, to explain how the original patch missed several attack vectors.

The original patch was meant to address a denial-of-service flaw on CSRSS (Client/Server Runtime Server Subsystem), the user-mode part of the Win32 subsystem.

However, when Cerrudo reverse engineered the bug to build an exploit, he found that that the vulnerability could still be exploited.
"The problem was that Microsoft didnt patch the vulnerable function; they just added some validation code before the call to the vulnerable function, but what Microsoft missed was that the vulnerable function can be reached from different paths and the validation code was added on just one of them," he said.

Click here to read more about patch quality concerns. "[The problem] is that Microsoft only patched one path to the vulnerable function, but they forgot to do proper research to identify all the paths," Cerrudo said.

In Cerrudos paper, he provides an analysis of the underlying vulnerability and the way Microsoft worked what he described as a "dumb fix" and noted that the companys coders eventually had to go back to the drawing board to create MS05-049, a bulletin that shipped in the October batch of patches.

Read more here about a Microsoft patch that didnt plug the vulnerability it was designed to fix. "[This MS05-049] fix is good, but Microsoft should have done it in the first patch," Cerrudo added.

"Microsoft failed to build a good fix, thus losing a lot of money and time," he said, noting that the time and resource costs are also borne by end users who had to apply two patches instead of one.

"I personally have seen Microsoft improvements on all aspects of security over the last years, but I think that Microsoft still needs some fine tuning on the patching process in order to avoid this kind of mistakes."

"The moral of the story: Always patch the vulnerable function or at least patch all paths to vulnerable function," he added.

The poor quality of the software giants patches has been a major black eye for the MSRC (Microsoft Security Response Center), the unit at Redmond that coordinates the software update process.

To read more about Microsoft pulling its Internet Explorer patches, click here. The company has invested heavily on improving the security response process, recruiting external patch testers and has implemented several new widely hailed initiatives, but patch quality remains a major nightmare.

Bulletin revisions to fix problematic patches have become a monthly occurrence, putting the MSRC within a rock and a hard place in the struggle to produce security fixes in a timely manner.

According to Dana Epp, a security consultant who tracks Microsofts security efforts, said the latest mistake proves that the human factor remains the "weakest link" in security.

"Even with the new secure programming paradigm at Microsoft, a recent set of patches show that the process is not perfect. Humans are fallible. Even the ones at Microsoft," Epp said in a blog entry discussing Cerrudos findings.

Epp said the specific error points to a "bigger problem" at Redmond because the company is well aware of the principles of checking string copy functions to stop buffer overflows.

"[These] principles seem to have been missed by the developers working on the patch."

Asked to respond to Cerrudos paper, a spokesperson for Microsoft said that both MS05-018 and MS05-049 address vulnerabilities that affect CSRSS, but noted that the later bulletin fixed a "new vulnerability that was not addressed as part of MS05-018."

In a brief statement, Microsoft said the original patch helps protect against the vulnerability discussed in in the MS05-018 bulletin, but the company did not address Cerrudos argument that the original patch never fully addressed the associated risks.

"MS05-049 does not replace MS05-018. Microsoft continues to encourage customers to download both MS05-018 and MS05-049, as well as all recent security updates," the spokesperson said.

Editors Note: This story was updated to include comments from Microsoft. Check out eWEEK.coms for Microsoft and Windows news, views and analysis.
 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel