Editorial Response to Microsoft Proposed Non-Disclosure of Vulnerabilities

Frankly, I was horrified this last month when Microsoft began to push for a new model for exploit disclosure. It is Microsoft�s contention that open disclosure forums like BugTraq aid crackers by exposing vulnerabilities to the underground at the same speed with which they are reported to vendors. Microsoft makes a good case for their position, stating that by providing technical details of exploits to the security community allows crackers to develop exploits, and even informs them of exploits of which they may not have been previously aware, before vendors can adequately produce and distribute a patch for customers. Their position is supported by incidents such as Nimda, SirCam, and IIS unicode directory traversal. In all of these cases speedy and accurate details of the vulnerability were published to security forums well before Microsoft could advise their mammoth customer base that vulnerabilities were present on their systems. Granted Microsoft has been taking a lot of heat lately over exploits of their IIS web server system. The response was well timed to their falling stature among several industry tracking firms and insurance agencies. Many on Bugtraq responded to the new Microsoft position with enthusiasm, and this was understandable. Even admins of *nix boxes were inconvenienced by the myriad of worms running amok on the net over the last few months as their logs and servers became flooded with probes for various Microsoft specific server holes. The lag on the net was noticeable to almost everyone as Code Red made the rounds.

While Microsoft has a good case to withhold vulnerability details from the security community until patches can be developed, the case that distribution of these patches should be delayed until customer bases can be notified, opens a time frame that is unacceptable. Also, withholding details of exploits severely hampers the ability of network administrators. While disclosure of details does in fact aid crackers, it can also be invaluable to systems administrators. It has been my experience that patching a system is always a risky and troublesome business. One never knows if the latest patch will have collateral impact on systems that do not share exact specifications for which the patch was developed. Given the amount of customization done to the average server by administrators based on customer and user demands almost any patch is rendered less than 100% reliable. Granted that many systems will respond well to a patch, small businesses that cannot afford a �crash� or sandbox machine to test patches on are severely hampered by patching and are given very little incentive to risk a crash for a patch. Disclosure of exploit details is essential to maintaining server security while also keeping uptime to a maximum. For instance, if recent exploits based on the �Scripts� directory can be circumvented in ways other than installing a patch (renaming the directory, moving it to a non-standard location, etc.) then that can be invaluable to many administrators. Without a full disclosure of exactly HOW an exploit is performed it is impossible for administrators to make informed decisions as to how to protect their systems. If a patch installation is the only viable option for administrators, not only will this promote administrator ignorance, but it also hobbles an administrator�s ability to respond to similar or future vulnerabilities.

Another good argument for full disclosure is the fact that few administrators have the time to develop an encyclopedic knowledge of exploits. Many administrators deploy a wide range of systems and configurations. Given the fact that many crackers collect libraries of exploits that are available only to themselves and their circle, crackers have the upper hand unless exploit code is fully disclosed. Being able to track vulnerabilities and their technical details in a public forum such as Bugtraq enables administrators to not only research specific system vulnerabilities to coincide with their systems, it also serves as a roadmap for exploit attempt signatures. If a system administrator spots a suspicious file that they know to be a prerequisite to a more expansive exploit, proper action can be taken. For instance, if a specific exploit requires multiple steps to perform a compromise, if an administrator can be made aware of these steps they can possibly intercept an exploit before its completion. Being aware of exactly how an exploit is performed also allows and administrator to cut off avenues of attack without necessarily having to change the systems that are directly vulnerable. Without full disclosure of exploit mechanisms administrators are denied a choice in their response to vulnerabilities. The list of examples is long enough that I�m sure readers can think of their own workaround to many of the exploits described in the security community without applying a specific patch.

Full disclosure has always been supported by the mantra �well, the black hats are going to know, so you may as well have the sysadmins know,� and this has never been more correct. If Microsoft begins to close its doors to vulnerability disclosure they will be hobbling their users and administrators. While, given Microsoft�s treatment of its customer base of late, this new stance won�t invoke much surprise from the community in general, the lesson needs to be learned in this instance lest other providers turn to the same model. Without disclosure informed administrators operate in the dark, with fewer choices for response, and limited understanding of their systems and their vulnerabilities. Hopefully this trend will begin and end with Microsoft, and given the nature of open source solutions thankfully this model shouldn�t spread to that sector of systems and software. I understand Microsoft�s response in terms of the average sysadmin (or even organizations that lack administrators) and their general client base, but they stand to alienate their most informed administrators (who I would presume are those MOST likely to turn to alternative solutions).

I encourage everyone who is able to resist this new Microsoft policy. If possible join Bugtraq (available at SecurityFocus.com), participate in discussions, and submit new exploit code, work arounds, and DETAILS. The security community must continue to be informed, regardless of vendor stance, lest we all become subject to the whim and discretion of vendor imposed decisions and solutions.