Certainly you've heard about the recent security concerns with Microsoft's Universal Plug and Play (UPnP) implementation. The problems let intruders completely take over an affected system. You can read more about the problems in our vulnerability report in the Discoveries and Hot News section on our Security Administrator home page.
Microsoft originally released Security Bulletin MS01-054 about UPnP on November 1, 2001, and later amended the bulletin on November 13. Yet, we're still finding other serious problems in the UPnP service. What's wrong with this picture?
On October 10, I wrote about Microsoft's new Strategic Technology Protection Program (STPP), which is designed to help companies "get secure and stay secure." I questioned whether such a program is enough to bolster the security of Windows-based networks, and Microsoft commented that it developed the new tools to help its developers write better code. Obviously the efforts are just not enough, as evidenced by the company's three attempts to eliminate serious problems with UPnP.
Even though Microsoft was aware of serious problems with its UPnP implementation, the company didn't make an adequate effort to discover and remedy all the possible bugs. This isn't the first time Microsoft has failed to thoroughly examine faulty components to ensure that all bugs are removed—it's happened numerous times over the years. So we're still left to wonder what other services and applications still contain gaping holes that leave users exposed to intruders. I suspect that when Microsoft first published Security Bulletin MS01-054, hackers immediately tried to discover how far Microsoft went toward correcting errors in its UPnP code. eEye Digital Security (who discovered this latest UPnP problem) once again reveals that Microsoft has fallen short of thorough research about services known to contain faults.
Why hasn't Microsoft applied its much-ballyhooed STPP program to itself? How can Microsoft lead companies to believe it can help secure their systems and networks through STPP when the company can't even squash all the known bugs in its application and service code? Why hasn't Microsoft contracted with excellent bug hunters (e.g., eEye Digital Security and others) to help investigate compiled code for dangerous risks?
The problem is glaring at this point, and Microsoft's lack is putting all Windows users at further risk. Microsoft will probably claim once again that writing bug-free code is incredibly difficult—which is true—and that it's hard to hunt down bugs in code after-the-fact. But as hackers continually prove, finding bugs is not as hard as some might wish us to believe. It simply takes time, money, and lots of cooperation—perimeters Microsoft should consider adopting. Read more on our Security Administrator home page.
Microsoft recently announced a new "Gold Certified Partner Program for Security Solutions" that through its membership guidelines prevents member companies from informing anyone about newly discovered security problems—presumably even their own customers—until Microsoft has developed and released a patch (see "Microsoft's New Partner Program for Security Solutions" on our Web site). Even after the patch becomes available, Microsoft forbids partners from publicly disclosing any details of vulnerabilities that might let nonpartners develop code to further investigate these vulnerabilities. How would those guidelines have affected the situation concerning this latest UPnP risk, given the fact that the bugs let someone hijack users' systems? Security consulting firms have rested on their laurels for years without any "gold certification" from Microsoft, so it's rather puzzling to contemplate how any partnership would benefit security researchers, consultants and Windows users.
We're conducting a new survey this week. We'd like to know if you think Microsoft should continue to hunt for security bugs on its own, contract with bug hunters, or release source code for public bug hunting efforts? Please stop by our home page and take the instant poll.
Before I sign off this week, I want to let you know that a reader pointed out that although Microsoft's Windows Update Web site is a decent and adequate service that truly helps users discover what patches they need to apply, the service lacks protection for customers who download and install patches. The Web-based service doesn't allow Secure Sockets Layer (SSL) connections and thus leaves the Windows update process more vulnerable to man-in-the-middle attacks. Surprised?
