Microsoft silently patched three vulnerabilities last month, two of them affecting enterprise mission-critical Exchange mail servers, without calling out the bugs in the accompanying advisories, a security expert said today.
Two of the three unannounced vulnerabilities, and the most serious of the trio, were packaged with MS10-024, an update to Exchange and Windows SMTP Service that Microsoft issued 13 April and tagged as "important," its second-highest threat ranking.
According to Ivan Arce, the chief technology officer of Core Security Technologies, Microsoft patched the bugs, but failed to disclose that it had done so.
"They're more important than the [two vulnerabilities] that Microsoft did disclose," said Arce. "That means [system] administrators may end up making the wrong decisions about applying the update. They need that information to assess the risk."
Core Labs researcher Nicolas Economou discovered the two unspoken bugs while digging into the update, part of his jobs as an exploit writer for Core, which is best known for its Core Impact penetration testing framework, a system for probing computers and networks for potential vulnerabilities by attacking them with real-world exploits.
"An attacker may leverage the two previously undisclosed vulnerabilities fixed by MS10-024 to spoof responses to any DNS query sent by the Windows SMTP service trivially," said Core in its own advisory on Economou's discovery. "DNS response spoofing and cache poisoning attacks are well known to have a variety of security implications with impact beyond just Denial of Service and Information Disclosure as originally stated in MS10-024."
DNS cache poisoning is a long-standing attack tactic -- it goes back nearly two decades - but is probably best known for the critical vulnerability in the Internet's Domain Name System (DNS) software found by Dan Kaminsky in 2008.
Secret patches are neither new or rare. "This has been going on for many years and the action in and of itself is not a huge conspiracy," said Andrew Storms, director of security operations at nCircle Security.
What is unusual is that Core took Microsoft's silent updates public.
Saying that Microsoft "misrepresented" and "underestimated" the criticality of MS10-024 because it didn't reveal the two bugs, Core urged company administrators to "consider re-assessing patch deployment priorities."
Core found a third unstated April 13 fix in another update, MS10-028. That patch addressed two identified bugs in Microsoft Visio, the company's project diagramming software.
Microsoft acknowledged it had fixed flaws without telling customers, but defended the practice.
"When a security vulnerability is discovered, Microsoft conducts a thorough investigation of that vulnerability, addresses any other issues found in the code as a result of that investigation and subjects the security updates to extensive testing for quality assurance," said Jerry Bryant, a security program manager, in an e-mail. "This helps reduce the number of updates customers have to deploy, since updating can be disruptive to customer environments."
If an internally-discovered flaw requires separate action or guidance not already covered by other vulnerabilities in the bulletin, "we would definitely document and address that vulnerability separately," Bryant said.
The truth is that it's business as usual for not just Microsoft, but for most software makers, said Storms. "Vendors commonly find bugs themselves in released code and will distribute the fixes inside a bundle of other patches," he noted. "Many times there simply is no benefit to anyone to disclose the bug."
In fact, Microsoft's policy is to not assign CVEs - the bug identifiers logged into the Common Vulnerabilities and Exposures database - to flaws found by its own researchers, said Storms. "There is no requirement for a vendor to request a CVE for internal bugs," he said.
But Storms also echoed Arce's concern about possible misuse of the practice, which could result in a false sense of security among users. "What's in question here is if the vendor misrepresents the risk and thus creates a false sense of lethargy with respect to the priority of patch distribution," he said. "For example, if an IE8 patch rated 'moderate' by Microsoft actually also contained a critical internally-found bug, would the lower rating put customers at risk because they may feel they could delay patch distribution, all along having no idea there was a hidden critical patch?"
Arce argued that that was exactly what Microsoft did in the case of MS10-024. "They fixed a very similar vulnerability in MS08-037 two years ago," he said, talking about the critical 2008 patch to plug the DNS vulnerabilities Kaminsky discovered. "If it wasn't a vulnerability then, why did they issue a vulnerability bulletin?" asked Arce. "There's no reasonable way for them to say this isn't a security problem."
"There is no easy answer for the vendor or customer," Storms said. "If the vendor distributed a critical patch, but with little information, like Adobe for example, we would all be hammering on the vendor for more information. On the other hand, given the workload on enterprise security teams we need to trust the vendor's rating to help determine priority."