Microsoft defends 'silent fix' patching rationale
Connecting state and local government leaders
"Silent fixes" are no cause for alarm for IT pros practicing good patch-testing techniques.
Microsoft explained its "silent fix" patching rationale earlier this week, but it's no cause for alarm for IT pros practicing good patch-testing techniques.
Jason Miller, leader of Shavlik Technologies' patch patrol team, explained that Microsoft's policy of looking for variant vulnerabilities in its software and then sending fixes in patches without describing the specific details is both routine and expected among the software security research community. Microsoft isn't exactly hiding anything. It's carrying out "due diligence" for its customers, he noted.
"Not only does the security community accept this approach, we expect this approach from the vendors," Miller stated via e-mail. "The vendor is expected to do their due diligence on protecting their customers and should be looking for these variants. The last thing any IT professional or security researchers want to see is patch release after patch release when the vulnerability and variants should have been taken care of the first time."
Silent fixes address vulnerabilities that aren't documented in Microsoft security bulletins, yet they relate to a specific documented problem in those security bulletins, according to a Microsoft blog post. Microsoft claims its silent fixes are for the variants, which the greater community of security researchers may be trying to track.
"We understand that researchers will reverse engineer our updates when released, and that they will look for similar security vulnerabilities to the one reported; these similar vulnerabilities we call variants," wrote Gavin Thomas, a Microsoft Security Response Center engineer, in the blog post.
Besides not being documented in the security update they're attached to, the variants are also excluded from the Common Vulnerability and Exposures (CVE) index -- a public database of known security vulnerabilities and exposures. Microsoft isn't publicly reporting the number of vulnerabilities associated with these variants.
"In many cases allocating a CVE would not be practical, for example, in some cases the security update is simply a back-port of code from a newer version of the product that has gone through the SDL [security development lifecycle] processes or perhaps the security update converted all unsafe string copy API calls to safe versions, Thomas wrote. "It's tough to know in cases like this how many vulnerabilities were addressed by this kind of bulk code change."
In some cases, security researchers have complained about Microsoft's silent fixes. For instance, last year, an official with Core Security Technologies complained about Microsoft fixing some Exchange flaws without noting the details in a security bulletin, according to a Computerworld article.
Miller noted that software vendors are in the best position to deal with variants due to their knowledge of the code.
"Many vulnerabilities are reported by external security researchers, but the vendor itself knows the code and can dig deeper into the issue. Security researchers may scratch the surface of the vulnerability or issue, but the vendor can find other issues that can and need to be fixed."
Could there be problems for IT pros patching systems when they can't obtain knowledge about these silent fixes? Miller sees it as more of a general issue. IT pros should test a patch before applying it.
"All patches have the potential of adversely affecting a system," he explained. "With fixing issues silently, there could be more potential fixes in a given patch, which increases the risk of adversely affecting a system. A patch is designed to fix a vulnerability (security patches) or issues that are not security related (non-security). As the patch fixes given issues, there is the potential the patch may break another aspect on the system."
Miller cited an Adobe Acrobat 9 patch issued last week that "broke printing functionality on some systems" as an example. However, he added that patches that break functionality have become "quite rare."
"With each patch, security and non-security, a good patch management policy has each organization testing the patches against a set of test machines before widely deploying to a corporate network," Miller explained.