In recent years, software manufacturers appeared to be increasing the transparency of communication about bugs. The Internet has allowed for rather rapid delivery of software patches, and Microsoft Corp. (Nasdaq: MSFT) even releases details in its security bulletins and accompanying Webcasts.
However, Core Security Technologies has revealed that in April, Microsoft patched two vulnerabilities that it did not disclose. While researching the fixes issued by Microsoft in Microsoft's Security Bulletin MS10-024 published April 13, 2010, exploit specialist Nicolás Economou discovered two vulnerabilities in Windows SMTP Service and Microsoft Exchange. These vulnerabilities were fixed by the patches referenced in MS10-024, but they were not disclosed in the vendor's security bulletin and did not have a unique vulnerability identifier assigned to them.
This situation revealed what Microsoft, and many other software vendors, are still hiding -- namely, the fact that they do not disclose internally discovered flaws.
What Core Security has helped to highlight is that once somebody else, perhaps a security firm or perhaps a hacker, reveals that a bug exists, then most software vendors will discuss that issue in the light of day. Essentially, the software vendors are transparent on the issue only when their hands are tied and they have to go public.
You might argue that if nobody knows about the flaw, why does it matter? But when you consider events like the March 13 patch-tastic Tuesday, you can see how overloaded IT departments have been just trying to keep PCs and servers up-to-date. If the public flaws are less serious than the hidden flaws, then there is the chance that in the challenge of juggling so many updates, they will place a low priority on a certain patch. The enterprise IT team may have a false sense of security because they don't have the full details.
Software vendors like Microsoft have a history of hiding update information. As recently as 2007, Microsoft was caught patching files
on Windows XP and Vista without users' knowledge, even when the users turned off auto-updates. This is one of the many reasons IT departments struggle with allowing software manufacturers free access onto the local network to push software updates.
Many system administrators have put in place automated management solutions that allow them to either test the updates themselves or rely on the testing from third parties like Shavlik Technologies or Core Security.
As the maker of an operating system, perhaps Microsoft has a higher responsibility to report these issues. Not only are enterprise IT departments making decisions based on what the vendor tells them, but there are tens of thousands of other software makers that build upon Windows. They rely on security updates, consolidated into databases like the CVE (Common Vulnerabilities and Exposures list), to decide what changes need to be made to their Windows-based software.
In the most recent case, Core Security urged company administrators to "consider re-assessing patch deployment priorities" if they have not already installed the patch for Microsoft Security Bulletin MS10-024. Though, in fairness to Microsoft, even without it including the two secret patches in this bulletin, the patch was given Microsoft's second-highest rating: "Important."
Even when you consider the two unreported flaws, the Important rating seems reasonable. It's unlikely that in this case, enterprise IT teams would have delayed this update.
However, the issue is still on the table: What happens when a critical bug goes unrevealed simply because it was discovered by a Microsoft employee?
And what happens when unreported bugs lead enterprise IT teams to make bad security decisions because they trusted the software vendor's security bulletins? Can IT teams really trust their vendors?
— David Silversmith is VP Information Technology at FirstBook.org, an organization that provides new books to children in need.